Verslag Bachelor Project. IN Bachelor Project van Arvind Mohabir Bilal Taouil Koen Boes

Verslag Bachelor Project

IN3405 - Bachelor Project van Arvind Mohabir - 1324810 Bilal Taouil - 1303570 Koen Boes - 1314785 ntry e-marketing

28 juni 2010 Version 1.0

Opdrachtgevers en begeleiders: Jasper van Blerk Derrick Stomp Peter van Nieuwenhuizen Universiteit Delft Faculty of Electrical Engineering, Mathematics and Computer Science

Samenvatting In opdracht van ntry e-marketing is er als proof-of-concept een softwarelaag ontwikkeld, die informatie van verschillende sociale profielensites verzamelt en combineert tot een enkel profiel in een aparte database. Dit profiel kan in beperkte vorm worden ingezien door andere gebruikers van de softwarelaag. De softwarelaag moet platform-onafhankelijk zijn en makkelijk te integreren zijn in de applicaties van ntry. De te onderzoeken profielensites zijn Hyves, Facebook, Last.FM, LinkedIn en Twitter. Te onderzoeken problemen zijn het (automatisch) inloggen en ophalen van informatie van de sociale profielensites, redundante informatie verwijderen en het plaatsen van informatie in context. Vanwege de eis voor platform-onafhankelijkheid en eenvoudige integratie is gekozen om van de softwarelaag een web service te maken. Om de werking van de web service aan te tonen, wordt naast de web service ook een test-applicatie ontwikkeld. De implementatie van het project maakt gebruik van de phasedrelease model methodiek. Hierbij wordt het project opgedeeld in kleinere projecten met elk hun eigen doelstellingen. Na elke fase komt er een werkend stuk programma uit. De implementatie is ingedeeld in drie delen. In de connectiefase worden de gegevens uit de profielensites gehaald en wordt er een inlogsysteem ontwikkeld, waarbij de gebruiker niet of nauwelijks hoeft in te loggen. Het opvragen van informatie van de sociale profielensites zou gedaan worden met hulp van beschikbare libraries. In de volgende fase, de koppelingsfase, moet alle informatie verzameld en gefilterd worden. Ook moet er een database worden opgezet om informatie op te slaan. De verkregen informatie wordt uiteindelijk in de database gezet. De laatste fase, de GUI-fase houdt in dat er een grafische interface voor een eindgebruiker ontwikkeld moet worden. Deze interface moet verbonden worden met een web service, die de softwarelaag draait. Het opvragen van gegevens bij de verschillende sociale profielensites ging niet vlekkeloos. Vanwege de moeizame implementatie is besloten om drie in plaats van vijf profielensites te implementeren. Van de beschikbare libraries voor de API’s van de profielensites voldeed alleen de library voor de Last.FM API. De library voor de Hyves API maakte gebruik van een verouderde versie van de API. Deze library is omgeschreven tot een library die compatibel is met de nieuwe 2.0 API. Ook de library voor de Facebook API maakte gebruik van een verouderde API. Dit is opgelost door gebruik te maken van de nieuwe Graph API. De informatie is uiteindelijk van de site gehaald door een zelfgemaakte connector. Het automatisch inloggen is opgelost door de inlogvensters op de achtergrond automatisch te laten invullen door de softwarelaag. De inloggegevens worden 2

niet onthouden. De koppelingsfase leverde geen grote problemen op. Ook het maken van een GUI en een web service veroorzaakte geen problemen. Het koppelen van de GUI met de web service leverde echter wel problemen op. Het automatisch inloggen ging niet goed. Dit kwam doordat een wachtend onderdeel niet goed onderbroken werd. Dit is opgelost door een kleine pauze in te lasten. Ook werd informatie niet goed doorgegeven over de web service. Dit bleek te liggen aan een serialisatie-optie bij het database-model. Aan de belangrijkste functies van de softwarelaag is voldaan. Niet alle profielensites zijn gemplementeerd. Dit bleek achteraf een goede keuze, omdat de implementatie van alle sites mogelijk tijdgebrek zou opleveren. Aan het phasedrelease model is gedeeltelijk gehouden. Aan de opgestelde fases is wel gehouden. Een fysiek product bij een fase is echter niet opgeleverd. De opdrachtgevers hebben de functionaliteit van de code echter wel gezien met behulp van code en tests. De softwarelaag is commercieel niet bruikbaar vanwege het automatisch inloggen. Dit is niet toegestaan door sommige API’s. Bij een eventuele voortgang van het project zou het inloggen aan de kant van de eindgebruiker moeten gebeuren. Ook zouden de andere profielensites toegevoegd kunnen worden. Het ophalen van de informatie zou sneller en efficinter kunnen en de beveiliging van de softwarelaag en database zou beter kunnen door bijvoorbeeld meer encryptie.

Voorwoord Dit verslag is geschreven door drie studenten technische informatica studerende aan de TU in Delft. Ter afronding van de bachelor kan een student te maken krijgen met een bachelorproject. De student is in dat geval gedurende 10 - 12 weken bezig met een opdracht voor een bedrijf. Via Jochen van Wylick, een ander student kwamen wij in contact met het bedrijf ntry e-marketing. Het bedrijf wordt geleid door Jasper van Blerk en Derrick Stomp. Vanuit de TU werd de begeleiding verzorgd door Peter van Nieuwenhuizen. Gedurende het bachelorproject werden we wat bewuster van onze opleiding. Het is niet altijd duidelijk van bepaalde vakken hoe ze in relatie staan tot de opleiding. Tijdens dit bachelorproject hebben we gebruik gemaakt van kennis van dit soort vakken. Tenslotte gaat onze speciale dank uit naar de begeleiders: Peter van Nieuwenhuizen, Derrick Stomp, Jasper van Blerk en Jochen van Wylick.

4

Inhoudsopgave 1 Introductie

7

2 Analyse 2.1 Opdrachtbeschrijving . . . . . . . . . . . . . . . . 2.1.1 Opdracht . . . . . . . . . . . . . . . . . . 2.1.2 Te onderzoeken sites . . . . . . . . . . . . 2.1.3 Doelstelling project . . . . . . . . . . . . . 2.1.4 Op te leveren producten en diensten . . . 2.2 Omgeving . . . . . . . . . . . . . . . . . . . . . . 2.2.1 Algemene kennis over het domein . . . . . 2.2.2 Klant en gebruiker . . . . . . . . . . . . . 2.2.3 De omgeving . . . . . . . . . . . . . . . . 2.2.4 Taken en procedures die eindgebruikers in uatie moeten uitvoeren . . . . . . . . . . 2.2.5 Concurrerende software . . . . . . . . . . 2.3 Eisen en beperkingen . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . de huidige . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . sit. . . . . . . . .

12 12 13

3 Ontwerp 3.1 Planning . . . . . . . . . . . . 3.2 Diagrammen . . . . . . . . . 3.2.1 Use Case diagram . . 3.2.2 Klassediagram . . . . 3.2.3 Databasediagram . . . 3.2.4 Sequence diagrammen

. . . . . .

. . . . . .

4 Implementatie 4.1 API’s en logins . . . . . . . . . . 4.1.1 Hyves . . . . . . . . . . . 4.1.2 Facebook . . . . . . . . . 4.1.3 Last.FM . . . . . . . . . . 4.1.4 JSON . . . . . . . . . . . 4.1.5 Logins . . . . . . . . . . . 4.2 Informatie verzamelen, filteren en 4.2.1 Verzamelen . . . . . . . . 4.2.2 Filteren . . . . . . . . . . 4.2.3 Categoriseren . . . . . . . 4.3 UI ontwikkelen . . . . . . . . . . 4.3.1 Ontwerp van de GUI . . . 5

9 9 9 10 11 11 11 11 12 12

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

15 15 15 15 17 18 18

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . categoriseren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

23 23 23 24 24 25 28 28 29 29 31 31 32

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

4.4

4.3.2 Testen 4.4.1 4.4.2

Koppeling tussen GUI en softwarelaag . . . . . . . . . . . . . . . . . . . . . . Integraal testen . . . . . . . . . . . . . Ervaring over het testen . . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

32 33 33 33

5 Conclusie 35 5.1 Resultaat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 5.2 Reflectie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 6 Aanbevelingen

A Vereisten Document Functionele vereisten . . Kwaliteit vereisten . . . Platform vereisten . . . Proces vereisten . . . .

39

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

41 41 42 43 43

B Domein Analyse 45 Introductie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Woordenlijst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Algemene kennis over het domein . . . . . . . . . . . . . . . . . . . . . 45 Klant en gebruiker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 De omgeving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Taken en procedures die gebruikers in de huidige situatie moeten uitvoeren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Concurrerende software . . . . . . . . . . . . . . . . . . . . . . . . . . 46 C Opdrachtbeschrijving 49 Opdrachtbeschrijving . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 D Diagrammen

51

E Plan van Aanpak

55

F Literatuuronderzoek API’s van verschillende sociale netwerk sites 79 G Literatuuronderzoek Programmeertalen

119

H Handleiding voor de webapplicatie

133

Hoofdstuk 1

Introductie Een steeds bekender wordend fenomeen is het gebruik van sociale profielensites. Elke profielensite heeft een ander doel. LinkedIn heeft bijvoorbeeld als doel om een profiel op zakelijk gebied bij te houden. Dit houdt ook in dat elke profielensite een andere soort gebruikers heeft. Vanwege de verschillende doelen heeft men profielen bij verschillende sites. De sites hebben naast verschillen ook overlapping. De typische informatie bij gebruikersprofielen, zoals naam en verjaardag, zouden gelijk moeten zijn bij de verschillende sites. Ook kan specifieke informatie, zoals evenementen en interesses, overeenkomen. Als laatste kunnen sociale contacten bij de verschillende sites overeenstemmen. De opdracht is om gegevens en evenementen te verzamelen van gebruikers op verschillende sites. Voor het verkrijgen van de evenementen wordt gebruik gemaakt van sociale profielensites, zoals Facebook en Hyves. De persoonlijke gegevens worden ordelijk op een rij gezet met de evenementen waar de gebruiker naar toe gaat. Tevens kan worden nagegaan welke gebruikers ook naar dit evenement gaan. De gebruiker kan afschermen wat andere gebruikers te zien krijgen afhankelijk van het soort evenement. De opdracht wordt uitgevoerd in opdracht van ntry e-marketing. Ntry emarketing is een bedrijf gevestigd in Leusden dat gespecialiseerd is op het gebied van e-marketing. Het bedrijf bestaat twee jaar en is eigendom van Derrick Stomp en Jasper van Blerk. Derrick Stomp is verantwoordelijk voor technische zaken op het gebied van e-marketing en Jasper van Blerk voor de grafische en commercile kant van e-marketing. Opdrachten worden uitgevoerd op het gebied van websiterealisatie, zoals zoekmachineoptimalisatie, adverteren op een zoekmachine en e-mailmarketing. De focus ligt tegenwoordig steeds meer op toepassingen voor het mobiele platform. In dit verslag zal de voortgang en implementatie van het project worden beschreven. In het volgende hoofdstuk “Analyse” zal de opdracht verder worden gespecificeerd, wordt de omgeving onderzocht en worden eisen en beperkingen opgesteld. Vervolgens zal het ontwerp worden uitgelegd met daarin de planning en de UML-diagrammen. Na het ontwerp zal dieper op de implementatie worden ingegaan. Hierin zullen de verschillende fases van de implementatie worden uitgelegd en worden de problemen bij implementatie en de gevonden 7

oplossing daarvoor besproken. Hierna zal in de conclusie de ervaringen van de leden beschreven worden. Als laatste zal door de uitvoerende leden een aantal toevoegingen en aanbevelingen worden gedaan over eventuele voortzetting van het product.

8

Hoofdstuk 2

Analyse In dit hoofdstuk zal de opdracht verder worden gespecificeerd, wordt de omgeving onderzocht en worden eisen en beperkingen opgesteld. De omgeving wordt onderzocht aan de hand van een domeinanalyse en informatie uit het plan van aanpak. De eisen en beperkingen komen uit het vereisten document.

2.1

Opdrachtbeschrijving

Voordat er begonnen wordt met implementeren moet eerst de opdracht duidelijk zijn. Als eerste wordt de opdracht gedefinieerd. Vervolgens wordt het doel van het project beschreven. Als laatste wordt het op te leveren resultaat opgesteld. Zie ook bijlage E.

2.1.1

Opdracht

De opdracht is om een algemene softwarelaag te maken die specifieke gegevens uit sociale profielensites haalt, deze filtert en vervolgens toont in een overzichtelijk testprogramma. De softwarelaag zou kunnen worden gebruikt in meerdere applicaties. De belangrijkste gegevens uit de sociale profielensites zijn gegevens van de gebruikers zelf, voorkeuren van de gebruikers en de evenementen waaraan ze meedoen. Er wordt uiteraard alleen informatie gebruikt waarvoor de ‘eigenaar’ toestemming heeft verleend. Evenementen kunnen door de gebruiker in een zelfgemaakte context worden geplaatst. De softwarelaag moet kunnen bepalen in welke context de informatie relevant is aan de hand van het soort evenement en eigen voorkeuren. Het moet mogelijk zijn om de softwarelaag later uit te breiden met gegevens van andere sociale profielensites dan de verderop genoemde sites en met meer gegevens van de reeds aanwezige sites. Ook moet het mogelijk zijn om naast evenementen bijvoorbeeld interesses en hobbies op te halen en in contexten te plaatsen voor een completer profiel. Op te lossen problemen zijn hierbij de mate van privacy van de gebruikers, opslag van accountgegevens en het voorkomen van redundantie. De privacy van de gebruikers is relevant, omdat de functie per sociale profielensite verschilt. LinkedIn is meer beroepsgericht dan Hyves en bevat meer zakelijke contacten. Gebruikers lijken geneigd om zakelijk en priv´e gescheiden te houden. Voor elke sociale profielensite moet een account worden aangemaakt om 9

in te kunnen loggen. Om bij de informatie te komen moet de softwarelaag toegang hebben tot deze accounts. Is het noodzakelijk om de gegevens van de verschillende accounts te bewaren of is het mogelijk om op een andere manier de accounts binnen te komen, bijvoorbeeld met een universele “inlog service”? Wanneer men ingeschreven staat bij meerdere sociale profielensites, kan het voorkomen dat dezelfde informatie op meerdere plekken staat. Daarnaast kan het zijn dat dezelfde informatie op een net andere manier geschreven is. Het is belangrijk om zo veel mogelijk dubbele informatie te filteren.

2.1.2

Te onderzoeken sites

Om externe evenementen te ontvangen is de keuze gevallen op bekende sociale profielensites. Uiteindelijk zijn er vijf belangrijke sites gekozen. Deze worden hieronder beschreven. Hyves Vooral in Nederland populair met 10 miljoen gebruikers en 5 miljoen actieve gebruikers. Hyves heeft een marktaandeel van ongeveer zestig procent en is veruit de grootste. Het is voornamelijk onder jongeren populair en wordt gebruikt voor prive-contacten met vrienden en familie. LinkedIn LinkedIn is voor een ouder publiek voor het onderhouden van professionele netwerken met collega’s. De doelgroep is de werkende hogeropgeleide man van rond de veertig jaar met ongeveer vijftien jaar ervaring. Zie bijlage E. Facebook Facebook is enigzins vergelijkbaar met Hyves, maar voegt de functie toe om kleine webapplicaties te draaien in de omgeving. Daarnaast wordt het internationaal veel gebruikt met meer dan 400 miljoen gebruikers. In Nederland neemt de populariteit steeds meer toe. Last.fm Last.fm is een online website die zich richt op internetradio en muziek. Op basis van beluisterde of bezochte artiesten maakt het Audioscrobbler-systeem achter Last.fm een lijst van aanbevelingen aan. Daarnaast is het mogelijk om met leden met dezelfde muzikale interesses in contact te komen. Twitter Twitter onderscheidt zichzelf van de rest door veelvuldig gebruik te maken van korte berichten genaamd tweets. Deze berichten kunnen gelezen worden door iedereen of alleen door vrienden van de gebruiker, als dit is aangegeven. De populariteit komt doordat op Twitter snel het laatste nieuws en de laatste feiten kunnen worden gepost. Nieuws kan hierdoor sneller en makkelijker naar de lezer toe komen, omdat de berichten niet noodzakelijk gemodereerd hoeven te worden. 10

2.1.3

Doelstelling project

Hier zullen we aanhalen waarom de opdrachtgever onze applicatie nodig heeft en wat hij er vervolgens mee wil bereiken. De connectie met sociale profielensites wordt gebruikt om: • Als een extra softwarelaag te dienen die gemakkelijk aangeroepen kan worden, ook door andere applicaties dan applicaties van ntry e-marketing. • Gegevens van verschillende sociale profielensites te aggregeren. • De verzamelde gegevens te gebruiken voor marketingdoeleinden.

2.1.4

Op te leveren producten en diensten

Hier zal worden uitgelegd wat het beoogde resultaat van dit project is en wat de opdrachtgever inhoudelijk van het product verwacht. Het resultaat Het resultaat moet een applicatie worden die informatie van verschillende sociale profielensites combineert en filtert. Interesses die op deze sites zijn opgegeven worden overgenomen in de vorm van tags. Eveneens is er de mogelijkheid om interesses aan te passen. Als laatste worden de evenementen waaraan de gebruiker meedoet, overgenomen. Wat verwacht de opdrachtgever De opdrachtgever verwacht op z’n minst een “proof of concept”, waar eventueel later mee verder kan worden gaan. Het is dus de bedoeling dat we alles duidelijk rapporteren en de softwarelaag ‘schaalbaar en modulair’ ontwerpen opdat het later makkelijk kan worden uitgebreid of worden aangepast. Het “proof of concept” moet tevens tags bijhouden, die gelinkt zijn aan contexten (die tevens moeten worden bijgehouden). Nadat gegevens zijn verzameld van de verschillende sociale profielensites en deze tags toegewezen hebben gekregen, kunnen deze gegevens worden gelinkt aan contexten met overeenkomende tags.

2.2

Omgeving

De omgeving bepaalt welke kant het project op moet gaan. Gebruikers bepalen waaraan de klant behoefte heeft en concurrenten bepalen aan welke behoefte wel en niet wordt voldaan. De omgeving kan ook bepalen welke beperkingen de opdracht heeft. Dit wordt in deze paragraaf uitgelegd.

2.2.1

Algemene kennis over het domein

Elke sociale profielensite heeft zijn eigen API. Deze worden ook wel web services genoemd in de context van een webapplicatie en bevatten vooraf ge¨ımplementeerde methodes, waar de softwarelaag gebruik van moet gaan maken. De communicatie tussen de softwarelaag en een API verloopt met behulp van XML. Verdere 11

uitleg over API’s en Web Services staat in de literatuuronderzoeken over API’s en programmeertalen. Zie bijlage F.

2.2.2

Klant en gebruiker

Deze applicatie zal te maken krijgen met verschillende actoren. We zullen ze hier kort aanhalen en uitleggen wat hun belangen zijn. Uiteraard is er de eindgebruiker. Eindgebruikers zullen van het systeem profiteren omdat ze veel informatie van hun profielensite en die van hun contacten nu makkelijk op een plek kunnen vinden. Echter moeten ze wel in eerste instantie de overstap maken. Dus moet de GUI, die op de softwarelaag komt, een gemakkelijke en gebruiksvriendelijke omgeving worden. Deze GUI valt er buiten de scope van dit project. Voordat de eindgebruiker van onze software kan profiteren moet het eerst worden gentegreerd in een ‘gebruikersomgeving’, die de features tot uiting brengt. Dus een andere belangrijke gebruiker is de softwareontwikkelaar die van deze service gebruik wil maken in zijn applicatie. Het is dus van belang dat onze software een duidelijke en makkelijke API krijgt. Een derde partij is de klant die deze laag op zijn server zal draaien. Voor deze partij is het van belang dat er geen privacy normen of regels worden gebroken. Dus moeten we daar bij het implementeren ook op letten.

2.2.3

De omgeving

Er worden geen specifieke eisen gesteld aan de omgeving. Echter is het wel een wens dat de applicatie zo min mogelijk ‘overhead’ veroorzaakt en een grote belasting aan kan. Daarnaast moet de softwarelaag kunnen communiceren met webapplicaties van “ntry e-marketing”. Dit zou echter geen probleem moeten zijn, omdat web services op dezelfde manier met elkaar communiceren. Dit is onafhankelijk van besturingssysteem en progammeertaal.

2.2.4

Taken en procedures die eindgebruikers in de huidige situatie moeten uitvoeren

In de huidige situatie zit er voor de gebruiker niets anders op dan de informatie op de verschillende sociale profielensites apart te bekijken en daaruit de relevante informatie op te zoeken. Om na te gaan wie naar een evenement toe gaat, moet op elke site apart gezocht worden naar het evenement. Pas als alle evenementen van de eindgebruiker van alle sites op een rij zijn gezet, kan gezocht worden naar personen die naar het evenement gaan.

2.2.5

Concurrerende software

Atomkeep Atomkeep houdt alle sociale profielen bijeen in een overzichtelijke interface. De keuze bestaat uit meer dan dertig sociale profielensites, waaronder LinkedIn, Twitter, Facebook en Last.FM. Er wordt een uitgebreid Atomkeep-profiel bijgehouden, die bij wijzigingen automatisch gegevens bij andere sociale profielensites 12

aanpast. Het heeft echter (nog) geen support voor de Nederlandse profielensite Hyves. Daarnaast moeten wachtwoorden steeds voor een aantal sites handmatig worden ingevoerd. Als laatste is er ook geen mobiele applicatie van Atomkeep beschikbaar. Atomkeep is nog steeds in beta. Een beperkt aantal gebruikers kan gebruik maken van de servers, omdat de capaciteit van de server nog niet optimaal is. FriendFeed Ook FriendFeed maakt gebruik van sociale profielensites om een duidelijk overzicht te geven van verschillende data. Het is mogelijk om vrienden in te delen in groepen en naar deze groepen specifieke informatie te sturen. Grote sites als Facebook, Google en Twitter worden ondersteund. Ook hier is nog geen ondersteuning voor Hyves. Het inloggen kan met een universele account, maar voor onderhoud is inloggen bij de desbetreffende site noodzakelijk. De service heeft als groot nadeel dat de contacten ook dezelfde service moeten hebben voor een volledig overzicht. FriendFeed heeft geen op zichzelf staand programma, maar wel een web interface gebouwd voor de iPhone. Flock Flock wijkt af van de andere aggregators, omdat het geen online applicatie is, maar een stand-alone applicatie in de vorm van een browser. De browser wordt gebouwd op de populaire browser Firefox. Informatie als wachtwoorden worden lokaal opgeslagen. Wanneer men met de applicatie op het internet aan het surfen is, wordt de gebruiker in real-time op de hoogte gebracht van veranderingen bij de sociale profielensites. Flock kan alleen als stand-alone applicatie gebruikt worden. Het is niet mogelijk om flock als plug-in voor andere browsers te gebruiken of om Flock op een mobiel platform te draaien. Een korte conclusie die uit de concurrerende software kan worden getrokken, is dat Hyves over het algemeen weinig wordt ondersteund en dat de software inloggegevens van de gebruiker moet worden onthouden of worden opgevraagd bij de gebruiker. Hyves wordt voornamelijk in Nederland gebruikt, wat het minder relevant maakt voor Engelse en internationale ontwikkelaars en gebruikers.

2.3

Eisen en beperkingen

Voor alle eisen en beperkingen wordt doorverwezen naar de bijlage A. Hieronder zullen een paar belangrijke eisen en beperkingen worden beschreven. • De applicatie moet binnen 10 `a 11 weken af zijn, omdat de deadline voor het project 2010/06/25 is. Indien nodig is een week uitloop mogelijk. • Tijdens het project moet een correcte ontwikkelmethodiek worden gevolgd. Dit is een vereiste van het project. Omdat de implementatie van het project in de planning is opgedeeld in fases, is er gekozen voor het phasedrelease model. Zie voor uitleg over het phased-release model bijlage E. • De softwarelaag moet (volledig) worden gedocumenteerd (in de zin van modellen e.d.). Dit is eveneens een belangrijk onderdeel van het project. 13

• Een beperking waar de softwarelaag gevoelig voor kan zijn, is dat het lastig wordt om het te “stress testen”. Dit komt doordat het moeilijk is een test omgeving op te zetten die duizenden gebruikers simuleert.

14

Hoofdstuk 3

Ontwerp Het gezegde gaat: Een goed begin is het halve werk. Daarom is een goed ontwerp belangrijk voordat de applicatie gemplementeerd wordt. Onderdelen van het ontwerp zijn het opstellen van een planning en het maken van diagrammen. Deze zullen in de opgenoemde volgorde beschreven worden met eerst de planning en dan de diagrammen.

3.1

Planning

De planning bij aanvang van de implementatiefase is weergegeven in het linkerfiguur in figuur 3.1. De uiteindelijk behaalde planning staat in het rechterfiguur in figuur 3.1. Voor het maken van de planning is gebruik gemaakt van het gratis programma GanttProject. De kleuren in het rechterfiguur in figuur 3.1 geven het uiteindelijk behaalde resultaat aan. Groen geeft de taken die op tijd af waren aan. Geel geeft de taken aan die niet op tijd af waren, maar nu wel af zijn. Blauw zijn de taken die overgeslagen zijn. Bij de implementatie van de API’s is besloten om het aantal API’s te verlagen naar drie in plaats van de ingeplande vijf. Achteraf was dit een goede keuze, omdat de implementatie van de drie API’s al de nodige problemen heeft opgeleverd. Het zou mogelijk moeten zijn om de overige API’s in te passen met minimale aanpassing van andere onderdelen van de softwarelaag. Alleen de SPSManager en de GUI zouden moeten worden aangepast.

3.2

Diagrammen

Diagrammen geven een goed overzicht over de structuur en werking van de softwarelaag en applicatie. Om te beginnen zal het Use Case diagram worden uitgelegd. Vervolgens zal het klassediagram beschreven worden. Daarna zal het databasediagram ter sprake komen. Tenslotte worden de sequence diagrammen uitgelicht.

3.2.1

Use Case diagram

Het Use Case diagram beschrijft de interactie tussen een applicatie en een actor. In dit geval is de applicatie de grafische interface voor de eindgebruiker en de 15

Figuur 3.1: Planning voor en na het project 16

actor is een eindgebruiker. Dit staat beschreven in figuur 3.2. De gebruikersomgeving is grotendeels gebaseerd op dit diagram. Figuur 3.2: Use Case diagram voor de gebruikersomgeving

3.2.2

Klassediagram

Een klassediagram, zie figuur 3.3, beschrijft alle klasses en methodes, die in een applicatie worden gebruikt. Dit klassediagram is gemaakt voor alleen de softwarelaag, omdat de grafische interface voornamelijk bestaat uit het aanroepen van de softwarelaag. Het is daarom niet nodig om een apart diagram te maken voor de GUI. De klasses en methodes die worden gemaakt, zijn met de gebruikersomgeving van Visual Studio gemaakt en wordt voor het grootste gedeelte automatisch gegenereerd. Het uiteindelijke klassediagram is net anders dan het vooraf bedachte diagram. Bij de SPSControllers zijn sommige wrappers/libraries niet gebruikt. Omdat informatie van Facebook en Hyves in JSON-formaat zijn verpakt, is de XML-parser vervangen door een JSON-parser genaamd JsonExSerializer. De 17

DataSetController is hernoemd tot SPS-manager en vangt de verschillende data van de verschillende sites op en zet deze objecten om in objecten die in de softwarelaag en database worden gebruikt. Dataset is hernoemd tot InfoSet en bevat een persoon, lijst van Events met de bijbehorende SPS-connecties, een lijst van Tags, een lijst met connecties tussen Events en Tags. De RedundancyFilter is gesplitst in twee verschillende filters: RedundancyFilter om redundante informatie uit de verschillende informatie van de sociale profielensites te filteren en DatabaseRedundancyFilter om redundante informatie in vergelijking tot de gegevens in de database te filteren. De RedundancyFilter wordt aangeroepen vanuit de SoftwareLayerController in plaats van de DatasetController. De DatabaseRedundancyFilter wordt aangeroepen vanuit de DatabaseController.

3.2.3

Databasediagram

Aangezien de informatie onthouden moet worden, worden de gegevens van de gebruiker op een vaste plek bewaard. Omdat de gebruiker op meerder locaties bij diens gegevens moet kunnen komen, zullen de gegevens online bewaard worden. Als keuze voor opslag is gekozen voor een database. Een weergave van het ontwerp en inhoud van de database is gegeven in figuur 3.4.

3.2.4

Sequence diagrammen

Voor het weergeven van de stroom van gegevens wordt gebruik gemaakt van sequence diagrammen. De uitwisseling van gegevens tussen verschillende klasses is duidelijk weergegeven. Voor drie verschillende situaties zijn diagrammen gemaakt. Als eerste is in figuur 3.5 beschreven wat moet gebeuren als een sociale profielensite wordt toegevoegd aan de account van een gebruiker. De gebruiker moet aanvankelijk aangeven dat een site toegevoegd moet worden aan het profiel in de database. Wanneer dit goedgekeurd is, kan na aanmelden de gegevens uit de site gehaald worden en opgeslagen worden in de database. In het diagram in figuur 3.6 wordt de login-procedure beschreven. De gebruiker doet een aanroep om in te loggen. Op de profielensites kan niet worden ingelogd vanwege een verlopen sessie. Aan de gebruiker wordt gevraagd zich in te loggen op de desbetreffende site. De token voor de sessie wordt opgehaald en wordt opgeslagen in de database voor mogelijk later gebruik. Het laatste diagram in figuur 3.7 toont de werking voor de toevoeging, bewerking en verwijdering van een context. De gebruiker geeft een verzoek om informatie in diens deel van de database aan te passen. Dit wordt doorgegeven aan de Database-controller, die een verzoek stuurt aan de database. Deze geeft een response terug of het gelukt is.

18

Figuur 3.3: Klassediagram voor de softwarelaag

19

Figuur 3.4: Databasediagram voor de opslag van gegevens van de sociale profielensites

20

Figuur 3.5: Sequencediagram voor de toevoeging van een sociale profielensite

Figuur 3.6: Sequencediagram voor het inloggen bij de softwarelaag en de sociale profielensites

21

Figuur 3.7: Sequencediagram voor de toevoeging, bewerking en verwijdering van een context

22

Hoofdstuk 4

Implementatie In dit hoofdstuk zullen de verschillende fases van de implementatieperiode worden beschreven. Zoals in het Plan van Aanpak beschreven staat, is er gewerkt volgens het phased-release model. Bij dit model wordt het project opgedeeld in kleinere subprojecten. Er is gekozen voor een opdeling van de implementatiefase in drie stukken. Als eerste worden de API’s aangesproken en moet de informatie van de sites automatisch worden opgehaald. Vervolgens moet de informatie van de verschillende sites worden verzameld, gefilterd en gecategoriseerd. Als laatste wordt een grafische interface gemaakt en gekoppeld aan de gemaakte softwarelaag. Ter afsluiting wordt het testen van het project besproken.

4.1

API’s en logins

Oorspronkelijke plan was om vijf sociale profielensites te benaderen. Om niet in tijdsgebrek te komen is later besloten om drie in plaats van vijf sites als uitgangspunt te nemen. Als er nog tijd over zou zijn, dan konden de overige twee profielensites alsnog worden gemplementeerd. De twee niet gemplementeerde sites zijn Twitter en LinkedIn. De drie benaderde sites zijn Hyves, Facebook en Last.FM.

4.1.1

Hyves

Voor Hyves is de library Bee.NET beschikbaar. Deze library is echter gebaseerd op de oude Hyves API 1.0. De oude API mist echter de mogelijkheid om evenementen terug te krijgen. Dit kan pas sinds de Hyves API 1.2 en inmiddels is er een nieuwe API 2.0. Omdat Bee.NET met het oog op webapplicaties is geschreven, is er nauwelijks ondersteuning voor een desktopapplicatie. Er was overwogen om de gegevens uit de API met eigen geschreven code te verkrijgen. Het lukte echter niet om voorbij de eerste stap van authenticatie te komen vanwege de ingewikkelde implementatie en onduidelijke documentatie. Daarop is besloten om de library om te schrijven naar een functionele library voor Hyves API 2.0. Dit leverde zo zijn problemen op, maar het was minder lastig dan aanvankelijk gedacht. De omgeschreven library werd voornamelijk gebruikt voor het authenticatie-proces. De ontbrekende evenementen-data wordt niet als object geretourneerd, maar als JSON-bestand. 23

Naast de gebruikelijke gegevens zoals tokens en oauth-gegevens heeft de authenticatie van Hyves ook een IP-adres nodig. Zonder het IP-adres gaat het berekenen van een geschikte sessiesleutel fout. Voor het aanmaken van de sleutel wordt de softwarelaag naar een speciaal opgezette pagina gestuurd op de ntry-server om de juiste sleutel te krijgen. Deze pagina staat op: http://in3405.ntrydev.com .

4.1.2

Facebook

Bij Facebook kan gebruik gemaakt worden van een REST API. Het oorspronkelijke plan was om een geschikte library voor C# te gebruiken voor het aanspreken van de Facebook REST API. De keuze voor een library was bedoeld om tijd te besparen en eenvoudig connectie te maken met de API. De library bleek uiteindelijk niet handig in gebruik en de REST API was te uitgebreid en ingewikkeld om snel informatie uit te krijgen. Eigen informatie bleek beperkt te zijn tot standaard informatie zoals gebruikersnaam, maar geen specifiekere informatie zoals een geboortedatum. Hiervoor zouden speciale toestemmingen moeten worden meegestuurd. Dit was slecht gedocumenteerd en niet handig in omgang. Facebook heeft sinds begin 2010 een nieuwe API beschikbaar, die door de ontwikkelaars van Facebook drastisch versimpeld is. De authenticatie is makkelijker dan met de oude API’s, de documentatie is beter en de verkregen informatie is duidelijker. Authenticatie kan gedaan worden door een gebruiker van de softwarelaag naar een speciaal opgezette site van Facebook te sturen en zich te laten inloggen. De API geeft een link terug met daarin een session key, waarmee de informatie uit de API verkregen kan worden. Het authenticeren gebeurt op de achtergrond met oAuth. Als men meer informatie uit de API wil halen, kan bij het authenticeren aan de gebruiker toestemming worden gevraagd voor meer toegang. Dit kan zijn voor meer persoonlijke gegevens of voor een langer houdbare session key. De mogelijkheden staan in de documentatie onder authenticatie en toestemmingen.

4.1.3

Last.FM

De Last.FM API heeft de mogelijkheid om informatie op te vragen via RESTverzoeken. Deze informatie wordt teruggegeven in de vorm van een JSONbestand of een XML-bestand. Last.FM maakt geen gebruik van oAuth, maar gebruikt een soortgelijk systeem. Als de gebruiker inlogt, wordt er een sessietoken teruggekeerd. De token heeft volgens de site een eeuwige geldigheidsduur. Voor Last.FM is een library beschikbaar genaamd lastfm-sharp. De laatste beschikbare library is al meer dan een jaar oud, maar dat lijkt het gebruik ervan niet te verhinderen op een paar kleine bugs na. Twee bugs springen in het oog: De evenementenlijst wordt niet goed teruggegeven en het opvragen van tags levert een opvallende bijkomstigheid. Wanneer men de evenementenlijst van een gebruiker opvraagt, wordt naast de goede evenementen ook een aantal evenementen met verkeerde eigenschappen in de lijst gezet. Bij alle foute gevallen geldt dat de identificatienummers van de evenementen een niet-bestaande evenement weergeven. Om dit op te lossen 24

wordt de lijst langs gegaan door van alle elementen de titel op te vragen. Bij een fout element wordt een exception gegooid. Deze exception wordt afgevangen en het desbetreffende element wordt uit de lijst verwijderd. Een andere bug treedt op bij het opvragen van tags van een artiest. Van een evenement kan niet rechtstreeks tags opgevraagd worden. Om tags te krijgen moeten eerst de artiesten opgevraagd worden. Van de belangrijkste artiest of artiesten wordt een klein aantal tags genomen. De opgevraagde tags komen per pagina van 100 entries. In een groot deel van de gevallen is er maar een enkele pagina beschikbaar. Soms komt het echter voor dat grote artiesten meerdere pagina’s met tags hebben. De library neemt dan in plaats van de afgesproken aantal tags een groter aantal tags. Het aantal tags is dan het afgesproken aantal maal het aantal pagina’s. Dit is niet opgelost, omdat het resultaat niet schadelijk is. Overbodige tags worden later eruit gehaald bij het filteren. Het gebruiksgemak van de library heeft echter als nadeel dat de library veel aanroepen moet doen. Dit betekent dat de snelheid niet hoog ligt. Bij een loop moet elk element worden opgevraagd bij de API, wat de snelheid niet ten goede komt. De gemiddelde duur van het proces is tussen tien en vijftien seconden. Het aantal aanroepen kan echter wel problemen opleveren, wanneer veel gebruikers tegelijk informatie proberen te verkrijgen. De API van Last.FM heeft geen duidelijke richtlijn voor het aantal aanroepen per seconde. Bij constant gebruik kan het programma-account geblokkeerd worden. De optimalisatie van de code zal mogelijk in de toekomst worden gedaan door de maker van de library.

4.1.4

JSON

Wanneer men informatie opvraagt bij de API, kan de informatie teruggeven worden in de vorm van een JSON-bestand. Een JSON-bestand lijkt op XML en is zowel door computers als door mensen goed te lezen. Een voorbeeld van een JSON-bestand staat in figuur 4.1. Voor het overzetten van JSON-bestanden in objecten is gebruik gemaakt van de library JsonExSerializer. De library is in eerste instantie bedoeld om objecten naar JSON-bestanden om te zetten, maar de mogelijkheid bestaat om het omgekeerde proces te doen. Elk attribuut en diens waarde in een JSON-bestand wordt als string opgeslagen. De namen in het bestand moeten letterlijk worden overgenomen als attribuutnaam in een zelf opgesteld object, zoals in figuur 4.2. Het type object moet worden meegegeven aan serializer. Het object dat uit de serializer komt, kan in de controller gebruikt worden voor het vullen van de infoset. De code voor de omzetting staat in figuur 4.3. 

Listing 4.1: Resultaat van een Facebook Graph API aanroep 1 2 3 4 5 6 7 8 9

10 11 12 13 14 15

{ ” id ” : ”220439” , ”name ” : ” B r e t T a y l o r ” , ” f i r s t n a m e ” : ” Bret ” , ” last name ” : ” Taylor ” , ” l i n k ” : ” h t t p : / /www. f a c e b o o k . com/ b t a y l o r ” , ”hometown ” : { ” id ” : 108363292521622 , ”name ” : ” Oakland , C a l i f o r n i a ” }, ” location ”: { ” id ” : 109650795719651 , ”name ” : ” Los Gatos , C a l i f o r n i a ” }, ” work ” : [

25

16

{ ” employer ” : { ” id ” : 20531316728 , ”name ” : ” Facebook ” }, ” position ”: { ” id ” : 111595812193665 , ”name ” : ” D i r e c t o r , Product ” }, ” s t a r t d a t e ” : ”2009 −08”

17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89

}, { ” employer ” : { ” id ” : 107618122602757 , ”name ” : ” F r i e n d F e e d ” }, ” position ”: { ” id ” : 115097051838153 , ”name ” : ” Founder & CEO” }, ” s t a r t d a t e ” : ”2007 −10” , ” e n d d a t e ” : ”2009 −08” } ], ” education ”: [ { ” school ”: { ” id ” : 112075895485567 , ”name ” : ” A c a l a n e s High ” }, ” year ” : { ” id ” : 108220712545752 , ”name ” : ”1998” } }, { ” school ”: { ” id ” : 6192688417 , ”name ” : ” S t a n f o r d U n i v e r s i t y ” }, ” year ” : { ” id ” : 108159685885670 , ”name ” : ”2002” }, ” concentration ”: [ { ” id ” : 111986405495645 , ”name ” : ” Computer S c i e n c e ” } ] }, { ” school ”: { ” id ” : 6192688417 , ”name ” : ” S t a n f o r d U n i v e r s i t y ” }, ” degree ”: { ” id ” : 113118705373612 , ”name ” : ”MS” }, ” year ” : { ” id ” : 111069712250208 , ”name ” : ”2003” }, ” concentration ”: [ { ” id ” : 111986405495645 , ”name ” : ” Computer S c i e n c e ” } ] } ], ” g e n d e r ” : ” male ” , ” u p d a t e d t i m e ” : ”2010−03−23T16 : 2 1 : 0 9 + 0 0 0 0 ”

26

90



}

Listing 4.2: Facebook User-object voor de serializer 1 2 3 4 5

using using using using using

System ; System . C o l l e c t i o n s . G e n e r i c ; System . Linq ; System . Text ; System . IO ;

6 7 8 9 10 11 12 13 14 15 16

namespace f a c e b o o k a p i { /∗∗ ∗ C l a s s f o r c o n v e r t e d u s e r −o b j e c t from u s e r Json− f i l e . ∗ Names o f p u b l i c a t t r i b u t e s s h o u l d be e x a c t l y t h e same a s i n t h e file . ∗∗/ p u b l i c c l a s s User { p u b l i c User ( ) { }

17

private string id ; p r i v a t e s t r i n g name ; private string firstName ; p r i v a t e s t r i n g lastName ; private string link ; private string birthday ; p r i v a t e Hometown hometown ; private Location location ; p r i v a t e L i s t <Work> work ; private string gender ;

18 19 20 21 22 23 24 25 26 27 28

public string id { get { return t h i s . i d ; } set { t h i s . i d = value ; } }

29 30 31

p u b l i c s t r i n g name { g e t { r e t u r n t h i s . name ; } s e t { t h i s . name = v a l u e ; } }

32 33 34

public string first name { get { return t h i s . firstName ; } set { t h i s . firstName = value ; } }

35 36 37

public s t r i n g last name { get { r e t u r n t h i s . lastName ; } set { t h i s . lastName = value ; } }

38 39 40

public string link { get { return t h i s . l i n k ; } set { t h i s . l i n k = value ; } }

41 42 43

public s t r i n g birthday { get { return t h i s . b i r t h d a y ; } set { t h i s . b i r t h d a y = value ; } }

44 45 46

p u b l i c Hometown hometown { g e t { r e t u r n t h i s . hometown ; } s e t { t h i s . hometown = v a l u e ; } }

47 48 49

public Location l o c a t i o n { get { return t h i s . l o c a t i o n ; } set { t h i s . l o c a t i o n = value ; } }

50 51 52

p u b l i c L i s t <Work> work { g e t { r e t u r n t h i s . work ; } s e t { t h i s . work = v a l u e ; } }

53 54 55

p u b l i c s t r i n g gender { get { return t h i s . gender ; } set { t h i s . gender = value ; } }

56 57

}

58 59

}

27



Listing 4.3: Omzetting van een JSON-bestand naar een object. T is in dit voorbeeld een Facebook User-object 1 2 3 4 5 6 7 8 9

10 11

/// <summary> /// Convert a Json− f i l e w i t h o b j e c t −i n f o i n t o an o b j e c t o f t y p e T . /// J s o n E x S e r i a l i z e r u s e d f o r c o n v e r t i o n . /// /// /// <param name=” path ”> /// p u b l i c T d e s e r i a l i z e J s o n O b j e c t ( s t r i n g j s o n O b j e c t ) { J s o n E x S e r i a l i z e r . S e r i a l i z e r s e r i a l i z e r = new J s o n E x S e r i a l i z e r . S e r i a l i z e r ( t y p e o f (T) ) ; T d e s e r i a l i z e d O b j e c t = (T) s e r i a l i z e r . D e s e r i a l i z e ( j s o n O b j e c t ) ;

12

return deserializedObject ;

13 14

}

4.1.5

Logins

Om informatie uit de profielensites te krijgen, moet de gebruiker toestemming geven. De gebruiker doet dit door in te loggen op de sites en door toestemming te geven middels een speciaal opgezette pagina. Dit levert echter het probleem op dat bij het ophalen van informatie de softwarelaag onderbroken wordt om de gebruiker toestemming te geven. Alleen bij Last.FM kan automatisch ingelogd worden met inloggegevens van de gebruiker zonder doorgestuurd te worden naar een pagina. Bij Hyves en Facebook moet de gebruiker op een aparte pagina inloggen. Als oplossing is hiervoor bedacht om de inloggegevens van de gebruiker door de softwarelaag automatisch in te laten vullen op de speciale pagina met behulp van html-elementen in de pagina. Een belangrijk punt is hier echter dat de sites de gebruiker toestemming laten geven om diens eigen privacy te laten beheren. Het is volgens de voorwaarden niet toegestaan om automatisch in te loggen. Als voorbeeld wordt aangedragen dat een gebruikersprofiel schadelijk aangepast of verwijderd kan worden. Omdat bij de softwarelaag het voorlopig om een prototype gaat, is het automatisch inloggen toch toegepast. Een oplossing voor een commercieel product is het verplaatsen van de login naar de kant van de client. Voor andere programmeurs zou dan kleine library beschikbaar gemaakt moeten worden, die het inloggen client-side afhandelt en de sessiesleutels verstuurd naar de web service.

4.2

Informatie verzamelen, filteren en categoriseren

Nu het mogelijk is om connecties te maken met de sociale profielensites, is de volgende stap om de informatie samen te voegen en klaar te maken om in de database geplaatst te worden. Als eerste wordt alle informatie verzameld. Vervolgens wordt de verzamelde informatie gefilterd en in de database gezet. Als laatste is er de mogelijkheid om de informatie achteraf te categoriseren. Deze drie punten worden hieronder beschreven. 28

4.2.1

Verzamelen

De gezochte informatie komt van verschillende sociale profielensites. Deze sociale profielensites geven op hun eigen manier de informatie terug. Dit wordt door een library of door de softwarelaag verwerkt tot een object uniek aan een sociale profielensite. Een Facebook-evenement heeft dus een apart Facebookevenement object in de softwarelaag. Deze specifieke objecten moeten worden verzameld voordat ze verwerkt worden. Voor het bijeenbrengen van informatie van een sociale profielensite is er een generiek object genaamd infoset gemaakt. In de infoset kunnen drie verschillende objecten gezet worden. Voor de infoset is een opbouw gekozen met als eerste een persoon, dan een lijst van evenementen en als laatste een lijst van tags. Binnen deze klasse is er nog een aparte tabel voor het bijhouden van connecties tussen evenementen en tags. De generieke objecten kunnen specifieke objecten van de sites of database zijn. Een generiek persoon kan dus een Facebook-persoon zijn, maar ook een Hyves-persoon of een persoon uit de database. De verschillende objecten moeten echter worden omgeschreven naar objecten, die in de softwarelaag gebruikt kunnen worden. Dit betekent dat de verschillende persoonsobjecten moeten worden omgezet naar een specifiek persoonsobject, dat in de database kan worden gezet. De SPSManager zorgt ervoor dat alle infosets worden omgezet naar een enkele infoset voor in de rest van de softwarelaag. Voor elke controller van een profielensite is er een converter beschikbaar. Voor het samenvoegen van de overgezette infosets gebruikt de SPSManager de merge-functie van de verschillende infosets om ze samen te voegen. De infoset wordt vervolgens weer doorgegeven aan de SPScontroller.

4.2.2

Filteren

Aanvankelijk zou het filteren van redundante informatie gebeuren in een enkele aparte klasse. Er is echter voor gekozen om deze op te splitsen in twee verschillende filters: Een filter voor de redundante informatie van de verschillende sites en een filter voor redundante informatie ten opzichte van de database. De keuze om de filter op te splitsen is vanwege de verschillende contexten waarin de informatie zich bevindt. Bij de eerste redundantie-filter zijn de gegevens net opgehaald. De consistentie tussen de opgehaalde gegevens moet onderzocht worden. Bij de tweede filter staat de informatie klaar om toegevoegd te worden in de database. Er moet nagegaan worden of er informatie in de infoset overeenkomt met informatie uit de database.

RedundancyFilter Bij het filteren van de infoset met gegevens van de verschillende sites wordt vooral op naam vergeleken. Alle tags worden met elkaar vergeleken door de naam te nemen, de letters in kleine letters te zetten en de karakters die geen letters of cijfers zijn eruit te filteren. De overgebleven namen worden met elkaar vergeleken. De evenementen worden op soortgelijke manier met elkaar vergeleken met als toevoeging dat de startdata en einddata met elkaar vergeleken worden. 29

Bij overeenkomst moet de laatst gevonden tag of evenement uit de lijst verwijderd worden en moet ook de crosslist bijgewerkt worden. De crosslist is een aparte lijst in de infoset, die de connectie tussen evenementen en tags weergeeft, zoals deze later in de crosstabel in de database moeten komen. Bij een te verwijderen evenement moeten de tags verplaatst worden naar het evenement waarmee het te verwijderen evenement overeenkomt. Daarnaast moet de lijst met sociale profielensites en de daarbijhorende evenementen-id’s worden overgeplaatst naar het andere evenement. Voor tags geldt een soortgelijk principe, alleen moeten alle evenementen worden langsgegaan en wordt nagegaan of een evenement de te verwijderen tag bevat. Als laatste wordt er een consistentie-check gedaan. Hierbij wordt nagegaan of alle elementen in de lijst van tags en alle elementen in de lijst van evenementen minstens een entry heeft in de crosslist. Als dit niet het geval is, wordt de infoset als ongeldig verklaard en geeft de methode een null-object terug. DatabaseRedundancyFilter Omdat de gegevens uit de database grotendeels bestaan uit de binnengekomen informatie uit de sociale profielensites, is de kans groot dat informatie in de infoset al in de database staat. De informatie uit de database kan intussen verouderd zijn. Evenementen kunnen al geweest zijn of de persoon in kwestie kan in een andere sector zijn gaan werken. Daarnaast is afgesproken om een vast aantal tags in de database beschikbaar te stellen in plaats van de tags te laten bepalen door de tags uit de sociale profielensites. Vanwege de eindige keuze is het makkelijker om contexten met elkaar te vergelijken. Als eerste wordt het persoonsobject vergeleken. Hierbij moet eerst nagegaan worden of de persoon al in de database staat. Voor het vergelijken wordt gebruik gemaakt van de naam van de persoon en de nickname van de login. Als het persoonsobject al in de database staat, kan het persoonsobject uit de infoset vergeleken worden met het object uit de database. Om de data zo recent mogelijk te houden wordt getracht om zo veel mogelijk informatie uit de infoset in de database te zetten. Vervolgens worden de evenementen met de evenementen uit de database vergeleken. Om een evenement van uniciteit te voorzien, wordt niet vergeleken op naam en data. Als meerdere personen een verjaardag op dezelfde datum hebben en dit evenement allemaal dezelfde naam ”Eigen Verjaardag”geven, dan kan er moeilijk onderscheid gemaakt worden. Een evenement is uniek, omdat een evenement een uniek identificatienummer heeft meegekregen bij een sociale profielensite. Dit geldt voor alle sites. Daarom is een crosstabel met sociale profielensites en evenementen gecreerd. Hierin staat onder andere de profielensite die aan het evenement gelinkt is, het id van het evenement in de evenemententabel en het unieke identificatienummer dat op de profielensite staat vermeld. Een evenement uit de infoset bevat een lijst met daarin de naam van de sociale profielensite en het evenementen-id die daarbij hoort. De naam en het id uit deze lijst wordt vergeleken met de elementen in de crosstabel van sociale profielensites en evenementen. Als dit overeenkomt, worden de gegevens in de 30

entry vergeleken met de informatie uit de infoset. De informatie wordt zo veel mogelijk vervangen door informatie uit de infoset. Zo wordt een evenement up to date gehouden. Omdat de database maar een eindig aantal zelf vastgestelde tags heeft, moeten tags in de infoset zo veel mogelijk vervangen worden door tags uit de database. Net zoals bij de andere filter worden de namen met elkaar vergeleken. Als een tag met dezelfde naam aanwezig is in de database, dan wordt de tag vervangen door de tag uit de database en wordt de crosslist hierop aangepast. Als een tag niet aanwezig is in de database, wordt deze verwijderd uit de taglist en wordt de crosslist bijgewerkt. Het kan dus zijn dat een evenement met voorheen tags zonder tags komt te zitten, omdat de tags niet in de database voorkomen.

4.2.3

Categoriseren

De softwarelaag biedt de mogelijkheid om gegevens van andere gebruikers te zien via evenementen. Stel dat er bij een gebruiker een evenement is, waar meerdere gebruikers naar toe gaan. Dan is het mogelijk om de gegevens en de evenementen te bekijken. Om gevoelige of overbodige informatie af te schermen, is het mogelijk om evenementen in een of meerdere contexten te plaatsen. Wanneer een gebruiker andermans evenementen wilt zien middels een gezamenlijk evenement, dan wordt alleen de evenementen getoond die in dezelfde context als het gekozen evenement zitten. Bij het binnenhalen van de informatie van de sociale profielensites worden de evenementen en tags standaard in een default context geplaatst. De gebruiker kan zelf de contexten naar wens aanpassen. De context wordt aangemaakt in de context-tabel van de database. Een context is gelinkt aan een persoon, een lijst met evenementen en een lijst met tags. Bij het maken van een context worden tags aan de context toegevoegd. Aan de hand van de tags kunnen de bijbehorende evenementen bepaald worden. Een evenement hoeft echter geen tags te hebben. Daarom bevat de softwarelaag de mogelijkheid om zowel tags als evenementen aan contexten toe te voegen. Bij het opvragen van evenementen van andere gebruikers moet worden meegegeven wat diens id is en via welk evenement de twee gebruikers gekoppeld zijn. Aan de hand van het opgegeven evenement kan worden nagegaan welke contexten bij het evenement en de persoon behoren. Van deze contexten worden de evenementen opgevraagd. Deze lijst met evenementen krijgt de gebruiker uiteindelijk te zien.

4.3

UI ontwikkelen

De softwarelaag kan pas van waarde zijn als deze wordt aangesproken. Een gebruikersomgeving is een goede manier om de werking van de softwarelaag te tonen. Het ontwerp van de GUI wordt besproken en de koppeling tussen de GUI en de softwarelaag wordt besproken. 31

4.3.1

Ontwerp van de GUI

Voor het ontwerp van de GUI is gekozen om een web applicatie te ontwikkelen. Een web applicatie is platform-onafhankelijk en de stap om de applicatie om te bouwen naar een mobiele applicatie is kleiner dan een desktopapplicatie om te bouwen. De opbouw van de applicatie komt grotendeels overeen met het use case diagram. Om gebruik te kunnen maken van de functionaliteit van de softwarelaag moet eerst ingelogd worden. Vervolgens is er de mogelijkheid om het profiel te bekijken of om instellingen van de sociale profielensites te bezichtigen. In de profielpagina is het mogelijk om andere gebruikers van een evenement te bekijken en om contexten aan te passen.

4.3.2

Koppeling tussen GUI en softwarelaag

De softwarelaag moet uiteindelijk met meerdere applicaties, platform-onafhankelijk, kunnen communiceren. Gekozen hiervoor is om een web service op de softwarelaag te bouwen. De web service wordt aangesproken via HTTP-requests en geeft informatie terug met behulp van HTTP-responses in XML- of JSON-formaat. Omdat een web service binnen Visual Studio standaard een SOAP web service kan maken, is gekozen voor een SOAP web service. De mogelijkheid bestaat om met kleine aanpassingen de SOAP web service om te zetten in een REST web service. Er rezen echter een paar problemen op bij het gebruik van de web service. Over te sturen elementen moeten serialiseerbaar zijn. Het inloggen bij de sites voor sessiesleutels leverde problemen op, wanneer de functie uitgevoerd wordt middels een web service. Serialisatie is het proces waarbij objecten worden overgezet in een formaat dat verstuurd kan worden over een netwerk of dat lokaal bewaard kan worden. Een serialisatie-optie in het database-model moest omgezet worden van None naar Unidirectional. Als deze optie niet gezet is, dan worden de connecties beide kanten op gedaan. Een persoon met verbindingen naar evenementen en sociale profielensites zal dan ook evenementen en sociale profielensites met meerdere personen hebben. Dit is geen probleem binnen de softwarelaag, maar bij het versturen van data levert het cyclisch gedrag problemen op. Bij de Unidirectional-optie wordt de connectie maar in een richting geplaatst. Een persoonsobject heeft cross-elementen zonder referenties naar andere objecten. Het inloggen bij de sociale profielensites ging goed bij het testen binnen de softwarelaag, maar leverde problemen op in combinatie met een web service. Een eerste gedachte was dat de event handlers niet goed overweg konden met de web service. Dit bleek niet het geval. Ook lag het niet aan de nieuwe thread die gestart wordt bij de uitvoering van de methode. Een ManualResetEvent werd gebruikt om te wachten op de event handlers. Het wachten wordt onderbroken, wanneer de laatste event is uitgevoerd. Dit bleek ook het geval, maar in dezelfde methode werd de ManualResetEvent gereset. Dit werd begrepen als niet onderbroken. Een kleine pauze heeft ervoor gezorgd dat de ManualResetEvent onderbroken wordt en pas daarna gereset wordt. 32

4.4

Testen

Om de functionaliteit van een applicatie in te schatten, moet de code getest worden. Met het testen worden fouten ontdekt en kan de code aangepast worden voor betere functionaliteit. Er zijn verschillende manieren voor het implementeren van testen. Voor dit project is gekozen om de code integraal te testen. Hieronder zal de betekenis, voordelen en nadelen van integraal testen worden beschreven en zal kort worden ingegaan op de ervaringen met integraal testen.

4.4.1

Integraal testen

Voor de implementatie is gekozen om een test-gedreven vorm van implementeren aan te houden. Dit houdt in dat aan het begin van implementatie een of meerdere tests worden geschreven. Aan de hand van de resultaten uit de test wordt de code gemplementeerd of aangepast. Zo kan worden nagegaan of aan alle voorwaarden is voldaan op het gebied van werking en randgevallen. Voordelen hiervan zijn dat de code zo correct mogelijk is en dat bij een steeds groter wordend project de kans op fouten binnen een component kleiner is. De fout ligt dan eerder bij de integratie tussen componenten. Het nadeel is de benodigde tijd voor het opstellen van een test. Het opzetten kan net zo veel of zelfs meer tijd kosten dan de implementatie van de code. Er wordt echter wel tijd gewonnen in een later stadium, omdat de fouten dan vaker veroorzaakt zijn bij de integratie en niet bij de losse componenten. Door de begeleider van het project werd later voorgesteld om de testen en implementatie niet door dezelfde persoon te laten schrijven. Het nut hiervan is dat diegene die de code schrijft, zijn tests mogelijk aanpast aan de code en dat door zijn code vaak bepaalde randgevallen over het hoofd gezien kunnen hebben. Het nadeel is dat een al tijdrovend proces nog langer kan duren vanwege gebrek aan kennis van het component. Vanwege de korte duur van het project is om deze reden hier toch van afgezien.

4.4.2

Ervaring over het testen

Testen zorgt ervoor dat mogelijke fouten in de code in een eerder stadium worden ontdekt. Componenten kunnen los van elkaar getest worden met hulp van dummy-objecten en zelf opgestelde test-objecten. Dit werkt voor lokaal fungerende componenten goed. Ook de onderdelen met connectie tot de database kunnen naar behoren getest worden. Het raadplegen van de database zorgt alleen voor een langere duur bij het testen. Bij het testen van asynchrone data-overdracht wordt het moeilijker. Dit was van toepassing bij de implementatie van het automatisch inlogsysteem. De inlog-methode krijgt pas een sleutel terug, wanneer de site een response teruggeeft. Het kan echter even duren voordat gereageerd wordt. Pas bij het ontvangen van een event kan de code verder nagekeken worden. Hiermee is in de programmeertaal rekening gehouden. In de code kan een korte pauze worden ingesteld.

33

34

Hoofdstuk 5

Conclusie In dit hoofdstuk zullen het resultaat van het project en de ervaringen van de leden worden besproken. Als eerste zal het resultaat aan de hand van opgestelde eisen in bijlage E en bijlage A besproken worden. Vervolgens worden de onderdelen die mee- en tegenvielen beschreven. Als laatste wordt verteld welke leermomenten uit het project gehaald zijn.

5.1

Resultaat

Voordat er begonnen was met implementeren, was met behulp van het MoSCoWmodel in bijlage E en een vereisten document, bijlage A, eisen aan het resultaat gesteld. De functionaliteit van het programma en de te gebruiken methodiek stonden hierin. Als eerste zullen de eisen besproken worden. Vervolgens wordt de gebruikte methodiek verder uitgelicht. Als laatste zal de bruikbaarheid van het product besproken worden. Bij het implementeren van de softwarelaag is vooral op de belangrijkste eisen uit het MoSCoW-model, de must-haves, geconcentreerd. Zie bijlage E. Deze hoofdeisen zijn uiteindelijk allemaal gemplementeerd en getest. Niet alle sites zijn gemplementeerd. Dit bleek achteraf een goede keuze te zijn geweest. Als alle sites gemplementeerd zouden worden, dan zouden we waarschijnlijk in tijdsgebrek zijn gekomen. Een web service is opgezet, maar het is geen REST web service. De output is wel in XML. De betrouwbaarheid van de web service is afhankelijk van de functionaliteit van de softwarelaag. Elke functie in de web service is in de softwarelaag aanwezig. Belangrijke op te lossen problemen waren het waarborgen van privacy van de gebruikers, de opslag van accountgegevens en het voorkomen van redundantie. Het probleem van de privacy is opgelost doordat je alleen gegevens van jezelf kan opvragen, waar je dan ook specifiek toestemming voor hebt gegeven. Bovendien vragen we nu alleen persoonsgegegevens en evenementen op, deze evenementen waren bij de profielensites publieke gegevens. Deze gegevens worden vervolgens opgeslagen en dus niet de account gegevens die nodig waren om in te loggen bij de profielensites. Het probleem van de account gegevens is dus ook afgehandeld, 35

wel wordt er een sessiesleutel voor elk van de profielensites opgeslagen zodat het de volgende keer mogelijk is gegevens op te vragen zonder in te loggen. De evenementen en persoonsgegevens worden ook gecontroleerd op dubbele informatie en deze word er vervolgens uitgehaald, dus ook dat probleem is afgehandeld. In het begin was door de leden afgesproken om volgens het phased-release model te werken. Hier is gedeeltelijk aan gehouden. Aan de opgestelde fases uit bijlage E is wel gehouden. Een fysiek product bij een fase is echter niet opgeleverd. De functionaliteit is getoond aan de opdrachtgevers middels het uitvoeren van tests en het uitleggen van de code. De softwarelaag is getest en werkt, maar de koppeling met web applicatie en web service levert af en toe nog problemen op. Commercieel kan de softwarelaag en web service niet worden toegepast vanwege het automatische inlogsysteem. Dit is in strijd met de opgestelde eisen van de API’s van de sociale profielensite. Het product is ontworpen met een prototype in gedachte en niet als commercieel product. Het product is echter wel degelijk een proof-of-concept. Om van de softwarelaag een commercieel product te maken moet het inloggen aan de kant van de client gedaan worden en moet de softwarelaag beter bestand zijn tegen eventuele fouten.

5.2

Reflectie

Gedurende de ontwerpfase werd er gevraagd om een planning te maken. Er moest geschat worden hoe lang een onderdeel zou duren. Dit werd door de leden van de groep als zeer moeilijk beschouwd en deels overbodig, omdat het natte vingerwerk was. We vroegen ons dus ook af: Hebben we eigenlijk wel een planning nodig? Doordat we niet goed wisten hoe lang een fase kon duren, hebben we de verschillende fases na de onderzoeksfase ruim ingepland. De planning was ook heel belangrijk voor onze begeleider en ntry e-marketing, omdat dit eigenlijk de enige maatstaf was om te zien hoe ver we waren. Aan het begin van het project wordt er automatisch veel gecommuniceerd tussen de leden van de groep en het bedrijf. Dit is logisch omdat de leden van de groep een goed beeld proberen te krijgen aan wat gewerkt moet worden. Door de vele informatie die verkregen is van ntry e-marketing, was het gevoel ontstaan dat we de opdracht compleet begrepen. Dit was niet helemaal zo, wat leidde tot het besteden van een halve dag aan een grotere database dan nodig was. Doordat er echter continue gecommuniceerd werd tussen ntry e-marketing en de leden van de groep, was dit maar bij een halve dag gebleven. Een combinatie van communicatie met de opdrachtgever en een opgesteld scenario maakte de opdracht duidelijker. Ondanks het goed communiceren van twee partijen, is het mogelijk dat je gedurende het project tegen tegenvallers aan loopt. Zo kwamen we al vroeg in het project erachter dat het niet gemakkelijk is om van elke API van de sociale profielensites even gemakkelijk informatie op te vragen. Zo kon er bij Last.fm al binnen een dag informatie opgevraagd worden. Hoewel er ongewenste informatie zat tussen de ontvangen gegevens van de Last.fm API, was deze connector 36

nog steeds ruim op tijd af. Bij Hyves en Facebook duurde het aanzienlijk langer (twee weken) voordat er informatie opgevraagd kon worden. Dit had hoofdzakelijk te maken met het authenticeren. Gedurende deze implementatie fase werd door ons begeleider Peter van Nieuwenhuizen aangeraden om in plaats van vijf, gebruik te maken van drie sociale profielensites. Dit bleek een hele goede keuze achteraf. Anders hadden we in plaats van drie werkende API’s waarschijnlijk vijf half werkende API’s. Nadat informatie wordt opgevraagd van de sociale profielensites, moesten we de verschillende API-aanroepen combineren tot een geheel. Bij het testen hiervan ontdekten we dat we veel tijd verloren door de methodes stapgewijs aan te roepen. Een stap kon pas aangeroepen worden als de vorige stap klaar is. Hier moesten we gebruik maken van threads. Een thread is een proces dat binnen een proces uitgevoerd wordt. Deze kunnen parallel worden uitgevoerd wat aanzienlijk tijd bespaart. Dit probleem zagen we niet van tevoren aan komen en kostte tijd waar we geen rekening mee hadden gehouden. Het opzetten van een GUI en een web service was geen probleem, maar de koppeling bleek enigszins problematisch te zijn. Het oversturen met behulp van serialisatie gaf af en toe problemen en het inloggen bij de sociale profielensites via de web services gaven kopzorgen. Het testen en het opzetten van de database zijn voorbeelden van waar de planning wel goed is verlopen. We hebben continue getest en dit leverde geen grote problemen op. Doordat we deze twee onderdelen ruimer hadden genomen, konden we hiermee de zware tegenvallers opheffen. Ondanks dat het heel moeilijk is om een planning te maken is het handig om er een te maken. De planning hoeft niet geheel accuraat te zijn, maar het geeft een goed beeld van wat er nog moet gaan gebeuren. Het heeft ook het voordeel dat je tegenover de betrokkenen bij het project een beeld kan geven van hoe ver het proces gevorderd is. Door uren te binden aan hoe lang fases zouden duren, zagen we in dat het handiger is om in plaats van vijf sociale profielensites drie sociale profielensites te proberen. Achteraf gezien hebben we dus een planning gemaakt waar we het grootste deel van de tijd aan gehouden hebben. De problemen die we hebben ondervonden, konden we van te voren niet goed aan zien komen. Om het authenticeren van de API’s van tevoren goed in te schatten ben je afhankelijk van de mensen die het eerder gemplementeerd hebben. Bij een soortgelijk project zouden we het project op hetzelfde manier onder handen nemen. We denken wel dat we door de ervaringen dat we hebben opgebouwd meer gevoel krijgen bij het oplossen van problemen en nog meer oog voor details hebben.

37

38

Hoofdstuk 6

Aanbevelingen In dit hoofdstuk worden de aanbevelingen van de groepsleden behandeld. De aanbevelingen zijn belangrijk voor diegene die willen voortborduren op het voortgebrachte prototype. Zo bevat het handige suggesties waar de groepsleden op zouden kunnen letten bij een verdere uitbreiding. In de interface van het prototype worden het wachtwoord en gebruikersnaam van een sociale profielensite ingevoerd voor authenticatie. De softwarelaag logt vervolgens in en de gebruiker wordt automatisch geauthenticeerd. Dit is volgens de voorwaarden van de sociale profielensites niet toegestaan. Dit kan er namelijk voor zorgen dat een gebruikersprofiel schadelijk wordt aangepast of zelfs verwijderd. Het inloggen en authenticeren moet in een commercile versie afgehandeld worden aan de kant van de eindgebruiker. Zoals eerder in de analyse is beschreven was het oorspronkelijke plan om vijf sociale profielensites te implementeren. Uiteindelijk zijn LinkedIn en Twitter niet gemplementeerd. Er is rekening gehouden in het prototype met een eventuele uitbreiding van het aantal sociale profielensites. Dit houdt in dat wanneer van een andere sociale profielensite informatie opgevraagd kan worden, het gebruik kan maken van de al gemplementeerde methodes om bijvoorbeeld opgehaalde informatie aan de database toe te voegen. In de database moet in de SPS-tabel een entry worden toegevoegd met de naam van de sociale profielensite. Voorlopig kunnen er alleen evenementen opgevraagd worden. Er is rekening gehouden met het opvragen van andere gegevens van een persoon. In het huidige prototype worden er dus evenementen opgehaald van de verschillende profielensites. Deze gegevens van gebruikers worden opgeslagen in de database. Het spreekt voor zich dat deze informatie goed beveiligd moet worden. Alleen wachtwoorden staan versleuteld in de database. Voor betere beveiliging moeten persoonlijke gegevens ook versleuteld worden in de database. Het inloggen bij de softwarelaag gebeurt nu door onversleuteld de inloggegevens over een onbeveiligde verbinding te sturen. Bij verbetering zouden deze gegevens met encryptie over een beveiligd kanaal moeten worden verstuurd. De web service en een webapplicatie moeten een overeenkomst sluiten over een te gebruiken encryptie.

39

Het prototype maakt gebruik van API’s van verschillende sociale profielensites. Elk van de API’s heeft een eigen verwerkingstijd voor de aanroepen die worden gedaan. Deze aanroepen van de verschillende API’s lopen nu parallel aan elkaar vanwege snelheidsoptimalisatie. Dit wordt gedaan met behulp van threads. Voor meer optimalisatie kan er gekozen worden om eigen API’s te implementeren. De gebruikte library van Last.FM neemt bij zelfs de meest eenvoudige methodes contact op met de Last.FM API. Zelfs bij het ophalen van de naam van een evenement bij een evenement-object roept het de Last.FM API aan. Bij het aanmaken van een object zou alle ingekomen data al verwerkt moeten zijn in het object. Het prototype is een web service waar verschillende methodes van het programma aangeroepen kunnen worden. Deze methodes achter elkaar zorgen ervoor dat de eindgebruiker zijn informatie kan ophalen en in de database kan zetten. Dit is nog niet echt gelijk aan een REST service. In het geval van een REST service wordt een object geretourneerd bij het invoeren van een unieke URL. Niet alle aanroepen zijn even geschikt om via een URL te doen. Het inloggen met de inloggegevens in de URL kan potentieel gevaarlijk zijn. Onderzoek naar de veiligheid van REST moet dus gedaan worden. Als de veiligheid niet gewaarborgd kan worden, bestaat er de mogelijkheid om het inloggedeelte te scheiden van het uitvoergedeelte. Facebook en Hyves gebruiken een soortgelijk principe, waarbij op een aparte pagina ingelogd moet worden. Voor dit project is gebruik gemaakt van C# en SQL Server van Microsoft. Dit zijn betaalde producten. Mono is een open-source programmeertaal met dezelfde syntax als C# en heeft een goede integratie met het .NET Framework. Onderzocht moet worden of het mogelijk is om de code automatisch over te zetten. SQL Server kan vervangen worden door MySQL. Er moet echter wel onderzocht worden of Linq-to-SQL wel compatibel is met andere databases.

40

Bijlage A

Vereisten Document Functionele vereisten Functionele vereisten moeten alles omvatten dat: • De gebruiker van een systeem moet weten wat betreft het systeem; • Andere systemen moeten weten om met dit systeem te kunnen communiceren. Implementatie details worden achterwege gelaten.

Interface API • Het eindproduct moet een gestandaardiseerde interface krijgen. Omdat het uiteindelijke product een webservice moet worden, wordt hier in de praktijk een RESTful interface bedoeld in plaats van een tradionele webservice interface(SOAP, WSDL EN UDDI). • De interface van de softwarelaag moet een aanvraag voor informatie accepteren. Vervolgens wordt informatie van sociale profielensites geretourneerd. • De interface moet een aanvraag voor een nieuwe account accepteren (waarin de profielensites van deze persoon zijn verwerkt) en reageren met inloggegevens. Ook kan er eventueel worden gevraagd om eenmalig onze softwarelaag toestemming te gegeven voor ´e´en of meerdere van de profielen sites. • Het systeem moet een aanvraag voor een aanpassing van een account accepteren en met een bevestiging reageren. • Het moet mogelijk zijn om een sociale profielensite toe te voegen of te verwijderen. • De gebruiker moet een context kunnen bewerken, verwijderen en toevoegen. 41

• De gebruiker moet een evenement kunnnen verwijderen. • De gebruiker moet zijn eigen profiel kunnen ‘updaten’. Op deze wijze worden aanpassingen, die gemaakt zijn op de gebruikers eigen sociale profielensites, opgenomen in de database.

Input/Output vereisten • De input en output moet taal en platform onafhankelijk zijn. Dit komt er op neer dat de interface gebruik moet maken van gestandaardiseerde protocollen. Specifiek zal gebruik worden gemaakt van het HTTP protocol aangezien het een RESTful interface moet worden. De inhoud van zo’n HTTP pakket zal XML zijn. • Persoonlijke gegevens kunnen niet opgevraagd of upgedate worden zonder eerst in te loggen.

Opgeslagen data • Het is gewenst dat geen gebruikersnamen en wachtwoorden van andere webservices worden opgeslagen. Het is enkel gewenst API-keys e.d. op te slaan. Dit om de privacy van de gebruiker te waarborgen. • Data van eerdere ‘updates’ (met tags) kan worden opslagen om overhead te verminderen. – Als gevolg moet bijgehouden worden of de opgeslagen data van een gebruiker nog accuraat is en niet al een keer voorkomt in de database. • Het opslaan van gegevens moet in een database gebeuren, omdat er van veel gebruikers gegevens moeten worden bijgehouden.

Berekeningen • Opgevraagde gegevens worden getagd. Dit gebeurt aan de hand van bestaande metadata aangeboden door andere webservices. • Aangezien een context meerdere evenementen bevat en deze evenementen op hun beurt weer meerdere tags met zich geassocieerd hebben, is het mogelijk contexten te vergelijken aan de hand van deze tags. Op deze manier moet aan de hand van contexten bepaald worden welke personen dezelfde interesses hebben. • Er moet gefilterd worden op dubbel voorkomende gegevens.

Kwaliteit vereisten Om te zorgen dat de softwarelaag van voldoende kwaliteit is, moeten de volgende algemene elementen opgenomen worden in de kwaliteitsvereisten: • Gebruiksvriendelijkheid 42

• Effici¨entie • Betrouwbaarheid • Onderhoudbaarheid • Herbruikbaarheid

Betrouwbaarheid en Beschikbaarheid • Kenmerkend voor een webservice is dat het constant in de lucht moet zijn. Dit moet ook gelden voor de softwarelaag, omdat dit uiteindelijk ook een webservice wordt. • De softwarelaag moet uiteindelijk een uitbreiding worden van andere applicaties. Om de reputatie van een bedrijf zoals ntry e-marketing hoog te houden kunnen onderdelen van software niet constant onbeschikbaar zijn.

Onderhoudbaarheid, uitbreidbaarheid en herbruikbaarheid • Het systeem moet een nauwkeurig gedocumenteerde interface krijgen. Omdat het een service moet worden die puur bedoeld is om ge¨ıntegreerd te worden in andere applicaties. • Het systeem moet modulair worden opgebouwd opdat componenten individueel kunnen worden vervangen of uitgebreid. Dit is van belang aangezien het eindproduct een prototype wordt. In een later fase moet het uitgebreid kunnen worden. Indien het nodig is, kunnen dan de interessante modules hergebruikt worden door een andere applicatie.

Platform vereisten Deze vereisten leggen beperkingen op de omgeving waar het systeem moet draaien en de technologie die gebruikt moet worden.

Techniek die gebruikt dient te worden • Dit wordt overgelaten aan de softwareontwikkelaars. Aangezien er geen specifieke vereisten zijn van uit de opdrachtgevers en van de TU Delft. Tevens is het geen uitbreiding op een ander applicatie, waardoor je niet aan een taal gebonden bent.

Proces vereisten Deze vereisten beperken het project plan en de ontwikkelmethoden die dienen te worden gebruikt. 43

Ontwikkelproces • Om de software te ontwikkelen wordt er gebruikt gemaakt van het ‘phasedrelease’ model. • Voor het testen van de softwarelaag worden er meerdere methodes gebruikt. Ten eerste wordt een ‘test-suite’ aangemaakt om continue te testen en ook wordt de ‘design by contract’ methode toegepast. Bij de eventuele GUI wordt ‘defensive programming’ gehanteerd. • De kwaliteit van de software wordt gewaarborgd door gebruik te maken van software voor het controleren van de programmeerstijl en de ‘code coverage’. Deze laatste is als plug-in beschikbaar voor Visual Studio 2010.

Kosten en leveringsdatum • De leveringsdatum staat gepland voor 2010/06/25 met een week uitloop. • De kosten zijn de kosten die uiteindelijk worden gerekend voor de server waar de software laag op zal gaan draaien.

44

Bijlage B

Domein Analyse Introductie Sociale profielensites zijn het domein van deze analyse. Het doel van dit project is het maken van een softwarelaag in dit gebied. De bedoeling van deze softwarelaag is om gegevens uit verschillende profielensites op een centrale plek beschikbaar te maken. Dit heeft als gevolg dat deze informatie beter te overzien en makkelijker te bereiken is. Tevens moet in het zelfde kader deze informatie in categori¨en geplaatst worden. Er moet van scratch een softwarelaag gemaakt worden (green-field developement). Dit houdt in dat de voorwaarden en eisen zelf opgesteld mogen worden.

Woordenlijst De terminologie wat betreft sociale profielensites is vrij recht door zee, echter zullen we toch een aantal termen noemen: Sociale profielensites zijn media ontworpen om ‘informatie’ te verspreiden door middel van sociale interactie met behulp van zeer toegankelijke en schaalbare publicatie-technieken. In dit geval wordt gebruik gemaakt van ‘web-based’ technieken, die dialogen toestaan in plaats van monologen (”broadcasts”). Application Programming Interface (API) is een ge¨ımplementeerde interface van een software programma om interactie met andere software in staat te stellen. Extensible Markup Language(XML) is een webstandaard voor het World Wide Web voor de syntaxis van formele markuptalen, waarmee men gestructureerde gegevens kan weergeven in de vorm van gewone tekst. Deze representatie is zowel leesbaar door machines als door de mens. Het XMLformaat wordt gebruikt om gegevens op te slaan en om gegevens over het internet te versturen

45

Algemene kennis over het domein Elke sociale profielensite heeft zijn eigen API. Deze worden ook wel web services genoemd in de context van een webapplicatie en bevatten vooraf ge¨ımplementeerde methodes, waar de softwarelaag gebruik van moet gaan maken. De communicatie tussen de softwarelaag en een API verloopt met behulp van XML.

Klant en gebruiker Deze applicatie zal te maken krijgen met verschillende actoren. We zullen ze hier kort aanhalen en uitleggen wat hun belangen zijn. Uiteraard is er de eindgebruiker. Eindgebruikers zullen van het systeem profiteren omdat ze veel informatie van hun profielensite en die van hun contacten nu makkelijk op een plek kunnen vinden. Echter moeten ze wel in eerste instantie de overstap maken. Dus moet de GUI, die op de softwarelaag komt, een gemakkelijke en gebruiksvriendelijke omgeving worden. Voordat de eindgebruiker van onze software kan profiteren moet het eerst worden gentegreerd in een ‘gebruikersomgeving’, die de features tot uiting brengt. Dus een andere belangrijke gebruiker is de softwareontwikkelaar die van deze service gebruik wil maken in zijn applicatie. Het is dus van belang dat onze software een duidelijke en makkelijke API krijgt. Een derde partij is de klant die deze laag op zijn server zal draaien. Voor deze partij is het van belang dat er geen privacy normen of regels worden gebroken. Dus moeten we daar bij het implementeren ook op letten.

De omgeving Er worden geen specifieke eisen gesteld aan de omgeving. Echter is het wel een wens dat de applicatie zo min mogelijk ‘overhead’ veroorzaakt en een grote belasting aan kan. Daarnaast moet de softwarelaag kunnen communiceren met de planningsapplicatie van “ntry e-marketing”. Dit zou echter geen probleem moeten zijn, omdat web services op dezelfde manier met elkaar communiceren. Dit is onafhankelijk van besturingssysteem en progammeertaal.

Taken en procedures die gebruikers in de huidige situatie moeten uitvoeren In de huidige situatie zit er voor de gebruiker niets anders op dan de informatie op verschillende sociale profielensites apart op deze sites te bekijken en daaruit de relevante informatie te op te zoeken. Om na te gaan wie naar een evenement toe gaat, moet op elke site apart gezocht worden naar het evenement. Pas als alle evenementen van alle sites op een rij zijn gezet, kan gezocht worden naar bekende personen die naar het evenement gaan. 46

Concurrerende software Atomkeep Atomkeep houdt alle sociale profielen bijeen in een overzichtelijke interface. De keuze bestaat uit meer dan dertig sociale profielensites, waaronder LinkedIn, Twitter, Facebook en Last.FM. Er wordt een uitgebreid Atomkeep-profiel bijgehouden, die bij wijzigingen automatisch gegevens bij andere sociale profielensites aanpast. Het heeft echter (nog) geen support voor de Nederlandse profielensite Hyves. Daarnaast moeten wachtwoorden steeds voor een aantal sites handmatig worden ingevoerd. Als laatste is er ook geen mobiele applicatie van Atomkeep beschikbaar. Atomkeep is nog steeds in beta. Een beperkt aantal gebruikers kan gebruik maken van de servers, omdat de capaciteit van de server nog niet optimaal is.

FriendFeed Ook FriendFeed maakt gebruik van sociale profielensites om een duidelijk overzicht te geven van verschillende data. Het is mogelijk om vrienden in te delen in groepen en naar deze groepen specifieke informatie te sturen. Grote sites als Facebook, Google en Twitter worden ondersteund. Ook hier is nog geen ondersteuning voor Hyves. Het inloggen kan met een universele account, maar voor onderhoud is inloggen bij de desbetreffende site noodzakelijk. De service heeft als groot nadeel dat de contacten ook dezelfde service moeten hebben voor een volledig overzicht. FriendFeed heeft geen op zichzelf staand programma, maar wel een web interface gebouwd voor de iPhone.

Flock Flock wijkt af van de andere aggregators, omdat het geen online applicatie is, maar een stand-alone applicatie in de vorm van een browser. De browser wordt gebouwd op de populaire browser Firefox. Informatie als wachtwoorden worden lokaal opgeslagen. Wanneer men met de applicatie op het internet aan het surfen is, wordt de gebruiker in real-time op de hoogte gebracht van veranderingen bij de sociale profielensites. Flock kan alleen als stand-alone applicatie gebruikt worden. Het is niet mogelijk om flock als plug-in voor andere browsers te gebruiken of om Flock op een mobiel platform te draaien. Een korte conclusie die uit de concurrerende software kan worden getrokken, is dat Hyves over het algemeen weinig wordt ondersteund en dat de software inloggegevens van de gebruiker moet worden onthouden of worden opgevraagd bij de gebruiker. Hyves wordt voornamelijk in Nederland gebruikt, wat het minder relevant maakt voor Engelse en internationale ontwikkelaars en gebruikers.

47

48

Bijlage C

Opdrachtbeschrijving Methode voor het aggregeren van social media profielen Sociale media websites zijn sterk in opkomst. Gebruikers hebben vaak profielen op meerdere sites zoals LinkedIn, Facebook, Twitter, Hyves, etc. De profielen worden afzonderlijk van elkaar onderhouden, waardoor voor de gebruiker redundantie in gegevens ontstaat. Een ander interessant aspect is dat informatie in een verschillende context een verschillende betekenis kan hebben. ntry e-marketing is bezig met het ontwikkelen van een applicatie waarmee informatie uit diverse social media bronnen met elkaar gekoppeld kan worden, waarbij we context en daarmee betekenis proberen te geven aan de informatie uit de social media bronnen. De eerste stap hiervoor is het vinden van een methode om informatie uit de verschillende bronnen op een betekenisvolle wijze samen te voegen. Grove vraagstellingen: • Welke technieken zijn er om profiel informatie uit de verschillende social media bronnen te verzamelen • Welke methoden zijn er mogelijk om de informatie uit verschillende bronnen te aggregeren Opdracht Schrijf een web applicatie die informatie uit verschillende social media bronnen verzameld, en deze op een logisch wijze ordent.

49

50

Bijlage D

Diagrammen

51

Figuur D.1: Klassediagram van de softwarelaag

52

Figuur D.2: Databasediagram van de softwarelaag

53

54

Bijlage E

Plan van Aanpak

55

Plan van aanpak

IN3405 - Bachelor Project van Arvind Mohabir - 1324810 Bilal Taouil - 1303570 Koen Boes - 1314785 ntry e-marketing

28 juni 2010 Version 1.1

Opdrachtgevers en begeleiders: Jasper van Blerk Derrick Stomp Peter van Nieuwenhuizen Universiteit Delft Faculty of Electrical Engineering, Mathematics and Computer Science

Samenvatting Door Ntry is een opdracht opgesteld om een softwarelaag te maken met als doel het logisch ordenen van en context geven aan informatie uit verschillende bronnen. Ter illustratie van de werking van de softwarelaag wordt daarnaast een simpele testapplicatie ontwikkeld. Bij deze opdracht worden vijf sociale profielensites doorzocht. De gekozen profielensites zijn: Hyves, Facebook, LinkedIn, Last.FM en Twitter. De profielensites moeten worden doorzocht op persoonlijke informatie en op evenementen. De persoonlijke informatie worden vervolgens gekoppeld aan de voorkeuren van de gebruiker en worden in de juiste context van voorkeuren en soort profielsites gezet. Voor deze opdracht staan er 10 weken ingepland.

Inhoudsopgave 1 Introductie

3

2 Projectopdracht 2.1 Projectomgeving . . . . . . . . . . . . 2.1.1 Hyves . . . . . . . . . . . . . . 2.1.2 LinkedIn . . . . . . . . . . . . . 2.1.3 Facebook . . . . . . . . . . . . 2.1.4 Last.fm . . . . . . . . . . . . . 2.1.5 Twitter . . . . . . . . . . . . . 2.2 Doelstelling project . . . . . . . . . . . 2.3 Opdrachtformulering . . . . . . . . . . 2.4 Op te leveren producten en diensten . 2.4.1 Het resultaat . . . . . . . . . . 2.4.2 Wat verwacht de opdrachtgever 2.5 Eisen en beperkingen . . . . . . . . . . 2.6 Voorwaarden . . . . . . . . . . . . . . 2.6.1 Projectleden . . . . . . . . . . 2.6.2 Opdrachtgever . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

5 5 5 6 6 6 6 6 6 8 8 8 9 9 9 10

3 Aanpak en tijdsplanning 3.1 Literatuuronderzoek en modelleren . . . . . . . 3.2 API’s en logins . . . . . . . . . . . . . . . . . . 3.3 Informatie verzamelen, filteren en categoriseren 3.4 UI ontwikkelen . . . . . . . . . . . . . . . . . . 3.5 Testen . . . . . . . . . . . . . . . . . . . . . . . 3.6 Tijdsplanning en feedback . . . . . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

11 11 11 12 12 12 13

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

4 Projectinrichting

17

5 Kwaliteitsborging

19

Bibliografie

20

Lijst van Figuren

21

2

Hoofdstuk 1

Introductie Bij het bezoeken van congressen is er de kans dat een bezoeker een of meerdere programmaboeken krijgt uitgedeeld. Het uitzoeken van geschikte programmaonderdelen uit een uitgebreid congres programma is een tijdrovende aangelegenheid. Dit was de aanleiding voor E-marketingbedrijf ntry om een sofwarelaag te laten ontwikkelen voor een mobiele plan applicatie om gemakkelijk evenementen en de bezoekers daarvan te verkrijgen. In te plannen evenementen worden aangeboden door de mobiele plan applicatie zelf of door derden. De opdracht is om deze evenementen te selecteren door gebruik te maken van sociale contacten. Voor het verkrijgen van de evenementen wordt gebruik gemaakt van sociale profielensites, zoals LinkedIn en Hyves. De persoonlijke gegevens wordt ordelijk op een rij gezet met de evenementen waar de gebruiker naar toe gaat. Tevens kan worden nagegaan welke gebruikers ook naar dit evenement gaan. De gebruiker kan afschermen wat andere gebruikers te zien krijgen afhankelijk van het soort evenement. In een later stadium kunnen de gegevens op deze sites gebruikt worden om te onderzoeken in welke evenementen de gebruiker geïnteresseerd is. Afhankelijk van het soort profiel en wensen kan nagegaan worden of de gebruiker hierin interesse heeft en of andere gebruikers dit interessant vinden. Dit wordt binnen de mobiele plan applicatie weer gebruikt om te matchen met een evenement dat al door de organisator is ingevoerd. Het volgende hoofdstuk, ‘Projectopdracht’, zal de aanleiding en het probleem beschrijven. Vervolgens worden de eisen en beperkingen van de opdracht opgesteld. In het derde hoofdstuk zal de aanpak worden uitgelegd en zal er een globale tijdsplanning worden gemaakt. Daarna zal in hoofdstuk 4 worden toegelicht hoe het project is ingericht en de middelen die aanwezig zijn. Als laatste zal een lijst van maatregelen worden opgesteld waardoor de kwaliteit van het project en het eindproduct gewaarborgd wordt.

3

4

Hoofdstuk 2

Projectopdracht In dit hoofdstuk wordt de gewenste verandering in beeld gebracht. De opdracht wordt afgebakend en vastgelegd zodat opdrachtgever en de projectmanager helder voor ogen krijgen waaraan het product zal moeten voldoen. Het heeft het karakter van een contract.

2.1

Projectomgeving

ntry e-marketing is een bedrijf gevestigd in Leusden dat gespecialiseerd is op het gebied van e-marketing. Het bedrijf bestaat twee jaar en is eigendom van Derrick Stomp en Jasper van Blerk. Derrick Stomp is verantwoordelijk voor technische zaken op het gebied van e-marketing en Jasper van Blerk op de grafische en commerciële zaken van e-marketing. Opdrachten worden uitgevoerd op het gebied van websiterealisatie, zoals zoekmachineoptimalisatie, adverteren op een zoekmachine en e-mailmarketing. De focus ligt laatste tijd steeds meer op toepassingen voor het mobiele platform. De probleemstelling is ontstaan door regelmatig bezoek aan congressen door de medewerkers van ntry. Door een overvloed aan (fysieke) informatie is het vrijwel onmogelijk om handmatig een goede selectie van evenementen te maken. Dit zou digitaal beter en overzichtelijker moeten kunnen. ntry heeft al een eigen mobiele applicatie voor persoonlijke planning . Hierop zouden zij graag willen voortborduren met de mogelijkheid om evenementen van buitenaf toe te kunnen voegen. Dit hoeven niet alleen zakelijke evenementen te zijn. Om deze externe evenementen te ontvangen is de keuze gevallen op bekende sociale profielensites. Uiteindelijk zijn er vijf belangrijke sites gekozen. Deze worden hieronder beschreven.

2.1.1

Hyves

Vooral in Nederland populair met 10 miljoen gebruikers en 5 miljoen actieve gebruikers. Hyves heeft een marktaandeel van ongeveer zestig procent en is veruit de grootste. Het is voornamelijk onder jongeren populair en wordt gebruikt voor prive-contacten met vrienden en familie. 5

2.1.2

LinkedIn

LinkedIn is voor een ouder publiek voor het onderhouden van professionele netwerken met collega’s. De doelgroep is de werkende hogeropgeleide man van rond de veertig jaar met ongeveer vijftien jaar ervaring [1].

2.1.3

Facebook

Facebook is enigzins vergelijkbaar met Hyves, maar voegt de functie toe om kleine webapplicaties te draaien in de omgeving. Daarnaast wordt het internationaal veel gebruikt met meer dan 400 miljoen gebruikers. In Nederland neemt de populariteit steeds meer toe.

2.1.4

Last.fm

Last.fm is een online website die zich richt op internetradio en muziek. Op basis van beluisterde of bezochte artiesten maakt het Audioscrobbler-systeem achter Last.fm een lijst van aanbevelingen aan. Daarnaast is het mogelijk om met leden met dezelfde muzikale interesses in contact te komen.

2.1.5

Twitter

Twitter onderscheidt zichzelf van de rest door veelvuldig gebruik te maken van korte berichten genaamd tweets. Deze berichten kunnen gelezen worden door iedereen of als dit is aangegeven door vrienden van de gebruiker. De populariteit komt doordat erop Twitter snel het laatste nieuws en de laatste feiten kunnen worden gepost. Nieuws kan hierdoor sneller er makkelijker naar de lezer toe komen, omdat de berichten niet noodzakelijk gemodereerd hoeven te worden.

2.2

Doelstelling project

Hier zullen we aanhalen waarom de opdrachtgever onze applicatie nodig heeft en wat hij er vervolgens mee wil bereiken. De connectie met sociale profielensites wordt gebruikt om: • De eigen mobiele plan applicatie uit te breiden met extra functionaliteit. • De verzamelde gegevens te gebruiken voor marketingdoeleinden

• Als een extra softwarelaag te dienen die gemakkelijk aangeroepen kan worden, ook door andere applicaties dan de mobiele plan applicatie.

2.3

Opdrachtformulering

De opdracht is om een algemene softwarelaag te maken die specifieke gegevens uit sociale profielensites haalt en deze verwerkt in een overzichtelijk testprogramma. De belangrijkste gegevens uit de sociale profielensites zijn gegevens van de gebruikers zelf, voorkeuren van de gebruikers en de evenementen waaraan ze meedoen. Er wordt uiteraard alleen informatie gebruikt waarvoor de ‘eigenaar’ toestemming heeft verleend. De softwarelaag moet zelf kunnen uitmaken 6

aan de hand van eigen (in het profiel staande of in het programma opgegeven) voorkeuren welke informatie relevant is voor de gebruiker. Ook moet het kunnen bepalen in welke context de informatie relevant is aan de hand van het soort profielensite en eigen voorkeuren. Het moet mogelijk zijn om de softwarelaag later uit te breiden met gegevens van andere sociale profielensites dan de eerder genoemde sites. Op te lossen problemen zijn hierbij de mate van privacy van de gebruikers, opslag van accountgegevens en het voorkomen van redundantie. De privacy van de gebruikers is relevant, omdat de functie per sociale profielensite verschilt. LinkedIn is meer beroepsgericht dan Hyves en bevat meer zakelijke contacten. Gebruikers zijn geneigd om zakelijk en privé gescheiden te houden. Voor elke sociale profielensite moet een account worden aangemaakt om in te kunnen loggen. Om bij de informatie te komen moet de softwarelaag toegang hebben tot deze accounts. Is het noodzakelijk om de gegevens van de verschillende accounts te bewaren of is het mogelijk om op een andere manier de accounts binnen te komen, bijvoorbeeld met een universele “inlog service”? Wanneer men ingeschreven staat bij meerdere sociale profielensites, kan het voorkomen dat dezelfde informatie op meerdere plekken staat. Daarnaast kan het zijn dat dezelfde informatie op een net andere manier geschreven is. Het is belangrijk om zo veel mogelijk overbodige informatie te filteren. Hieronder staat een lijst van eisen waaraan de softwarelaag en het programma moeten voldoen. Dit is gedaan aan de hand van het MoSCoW-model. Dit model geeft aan wat essentieel is voor het programma (Must haves), wat mogelijk nog gedaan zou kunnen worden wanneer er tijd beschikbaar is (Should haves) en wat er gedaan kan worden als we echt snel klaar zijn (Could haves en Want to haves). Het laatst genoemde is bedoeld voor mogelijke toekomstige versies. Must haves • De vijf eerder besproken sociale profielensites kunnen benaderen. • Data van deze sites kunnen opvragen. • Tags aan data kunnen geven. • Data koppelen aan een context. (Dat is het segment waarin eigenschappen zitten die door de gebruiker zijn gedefinieerd. Alles wat daar onder valt, krijgt een label met de naam an die context.) • Dubbele data (redundantie) voorkomen. • Inloggen met een bestaande (liefst universele) account. – Inloggegevens van profielensites opgeven.

– Inloggen op profielensites (als facebook) zonder bij alle sites elke keer handmatig inloggen en toestemming geven. – Inloggen met een universele account. • Een simpele interface ter illustratie van de werking van softwarelaag. Alleen aan te roepen op het systeem waar de softwarelaag draait. 7

Should haves • Zelf evenement opzoeken door een zoek-functie. • Data matchen (vraag en aanbod). Could haves • Niet alleen evenementen, maar ook andere interesses kunnen invoeren in de zoek-functie. • Andere sociale profielensites toevoegen. Want to have • Uitgebreide Grafische User Interface met mogelijk een web interface. • Data opslaan op sociale profielensites.

• Softwarelaag verbinden met de mobiele plan applicatie en functionaliteit aan deze mobiele plan applicatie toevoegen. De belangrijkste data zijn persoonlijke informatie, evenementen, beroep en/of opleiding, locatie en datum. Beroep en opleiding kan belangrijk zijn voor de relevantie van een evenement. Visuele content is in dit geval minder belangrijk dan tekst om te bepalen welke evenementen belangrijk zijn. Onder evenementen wordt verstaan grote festivals, concerten en meer zakelijke evenementen zoals beurzen. De data moet verwerkt worden als het programma wordt opgestart of als de gebruiker vraagt om een handmatige verversing. Bepaalde data zal moeten worden opgeslagen in een database. Welke gegevens dat precies zullen zijn zal na het literatuuronderzoek beter kunnen worden vastgesteld.

2.4

Op te leveren producten en diensten

Hier zal worden uitgelegd wat het beoogde resultaat van dit project is en wat de opdrachtgever inhoudelijk van het product verwacht.

2.4.1

Het resultaat

Het resultaat moet een applicatie worden die informatie van verschillende sociale profielensites combineert en filtert. Interesses die op deze sites zijn opgegeven worden overgenomen. Eveneens is er de mogelijk om interesses aan te passen. Als laatste worden de evenementen waaraan de gebruiker meedoet, overgenomen.

2.4.2

Wat verwacht de opdrachtgever

De opdrachtgever verwacht op z’n minst een “proof of concept”, waar eventueel later mee verder kan worden gaan. Het is dus de bedoeling dat we alles duidelijk rapporteren en de softwarelaag ‘schaalbaar en modulair’ ontwerpen opdat het later makkelijk kan worden uitgebreid of worden aangepast. Het “proof of concept” moet tevens tags bijhouden, die gelinkt zijn aan categorieën (die tevens moeten worden bijgehouden). Nadat gegevens zijn verzameld 8

van de verschillende sociale profielensites en deze tags toegewezen hebben gekregen, kunnen deze gegevens worden gelinkt aan categorieën met overeenkomende tags.

2.5

Eisen en beperkingen

Nu zullen we de eisen, die aan het product worden gesteld en de totstandkoming, zo nauwkeurig mogelijk kwantificeren en vaststellen. De eisen en beperkingen waaraan het product en project respectievelijk moeten voldoen of gevoelig voor zijn: • De applicatie moet binnen 10 à 11 weken af zijn, omdat de deadline voor het project 2010/06/25 is met een week uitloop. • Tijdens het project moet een correcte ontwikkelmethodiek worden gevolgd. Dit is een vereiste van het project. Omdat de implementatie van het project in de planning is opgedeeld in fases, is er gekozen voor het phasedrelease model1 . Zie ook figuur 2.1. • De softwarelaag moet (volledig) worden gedocumenteerd (in de zin van modellen e.d.), dit is tevens een belangrijk onderdeel van het project. • Een beperking waar de softwarelaag gevoelig voor kan zijn, is dat het lastig wordt om het te “stress testen”. Dit komt doordat het moeilijk is een test omgeving op te zetten die duizenden gebruikers simuleert.

2.6

Voorwaarden

In deze sectie worden de verantwoordelijkheden van de projectleden en opdrachtgever vastgesteld, alsmede die van de projectmanager en derden, om de gestelde eisen waar te kunnen maken.

2.6.1

Projectleden

Het volgende wordt van de projectleden verwacht: • Er moet 10/11 weken, 5 dagen per week, 8 uur per dag aan het project worden gewerkt om het tijdig te kunnen realiseren. • Duidelijke documentatie bijhouden. Voor elke fase wordt een kort plan van aanpak vastgesteld, een kort stuk geschreven over de implementatie, een kort stuk over het testen van de fase en een korte reflectie. 1

• Een correcte ontwikkelmethodiek volgen.

Het phased-release model is een software model dat een incrementeel ontwikkelproces ondersteunt. Het stelt voor dat het project, na het verkrijgen van eisen en het plannen, wordt opgebroken in aparte subprojecten of fases. Elke subproject kan apart worden afgeleverd aan de opdrachtgever [2].

9

Figuur 2.1: Het phased-release model, in dit geval met twee fases

2.6.2

Opdrachtgever

Het volgende wordt van de opdrachtgevers verwacht: • De opdrachtgevers moeten twee dagen per week één uur de tijd hebben voor overleg, om de voortgang of nieuwe ideeën te bespreken. • De opdrachtgevers moeten (in ieder geval twee keer per week) werkplekken beschikbaar stellen met een internet verbinding.

10

Hoofdstuk 3

Aanpak en tijdsplanning In dit hoofdstuk wordt aangegeven hoe te kunnen voldoen aan de in sectie 2.5 gestelde eisen. Hierbij wordt de fasering van het project besproken en wordt aangegeven van welke aannames wordt uitgegaan. Vervolgens is een lijst met activiteiten opgesteld en is een schatting gemaakt van de benodigde tijd voor deze activiteiten. Op grond hiervan is een tijdsplanning gegeven met bijbehorende mijlpalen. Hierbij is ook aangegeven op welke momenten input van de opdrachtgever nodig is en wanneer terugkoppeling plaatsvindt. Aan de hand van het ‘phased-release’ model is de planning onderverdeeld in een “documentatie en modelleer” deel, section 3.1, en drie implementatie fases, resp. section 3.2, 3.3 en 3.4. De UI wordt pas in de laatste fase geïmplementeerd, omdat het de software, ontwikkeld in de voorgaande fases, nodig heeft als basis. Verder wordt er ook aandacht besteed aan de manier van testen die gebruikt wordt.

3.1

Literatuuronderzoek en modelleren

• Literatuuronderzoek doen naar de API’s van verschillende sociale profielensites. • Literatuuronderzoek doen naar programmeertalen en een te volgen ontwikkel methodiek. • Modellen voor implementatie creëren.

3.2

API’s en logins

• Connecties tussen de API’s1 en de softwarelaag maken. • Creëren van een loginsysteem zonder alle andere logins nodig te hebben. (Bijvoorbeeld met OpenID of OAuth) 1

Zie de woordenlijst in de domein analyse voor de betekenis, mocht deze onbekend zijn.

11

3.3

Informatie verzamelen, filteren en categoriseren

• Data uit API halen en tags geven.

• Redundante informatie en/of tags wegfilteren. • Koppeling creeren tussen tags en context.

3.4

UI ontwikkelen

• Implementatie van een simpele GUI. • GUI koppelen met softwarelaag.

3.5

Testen

Tijdens het project zal uitvoerig getest worden. Hieronder zal worden uitgelegd hoe de ontwikkelaars van plan zijn dat in de praktijk te brengen. Tijdens het implementeren zullen er geen specifieke test momenten zijn, omdat het plan is om ‘test-based’ te implementeren. Om te kunnen uitvoeren, moet er een testsuite worden opgezet. In Java wordt dit gedaan met een aparte testsuite genaamd Junit, maar Visual Studio heeft een ingebouwde testsuite met functionaliteit voor automatische uitvoering.. Dit maakt een extern programma overbodig. Vervolgens kunnen we deze ‘test-suite’ tijdens en na het implementeren op de code “draaien”. Dit maakt het mogelijk om te unit testen, intergratie testen en systeem testen. Op deze manier kom je er meteen achter of de code voldoet aan de vastgestelde specificaties. Omdat het niet mogelijk is om bepaalde klasses in verbinding met een server direct te testen, zijn er stubimplementaties voor deze klasses speciaal voor testen beschikbaar gesteld. De library met deze implementaties staat in System.Web.Abstractions.dll. Ook zijn we van plan de ‘design by contract2 ’ methodiek te hanteren in de softwarelaag die we gaan ontwikkelen. In de GUI zullen we echter de ‘defensive programming3 ’ methodiek hanteren. Mochten aanroepen dus eventueel niet aan een contract voldoen, dan worden deze opgevangen in de interface. Dit voorkomt dat de gebruiker een foutmelding krijgt uit de softwarelaag. Eveneens wordt de kwaliteit van de software gewaarborgd door gebruik te maken van software voor het controleren van de programmeerstijl en de ‘code coverage’. Visual Studio heeft een ingebouwde functie voor code coverage, maar niet voor programmeerstijl. Het nakijken van de programmerstijl is niet vitaal voor de functionaliteit van het systeem. Als laatste heeft Visual Studio voor de berekening van de performance ook functionaliteit. Om de tijdsduur van een functie te berekenen, is binnen de System.Diagnostics de klasse Stopwatch aanwezig. Daarnaast is er ook de ’performance wizard’, die applicaties analyseert op processor verbruik, afhankelijkheid en tijdsduur. Ten slotte is het ook mogelijk om een hoge capaciteit op de softwarelaag na te bootsen door middel van een load test. Bij deze test worden 12

verschillende gebruikers gesimuleerd die simultaan gebruik maken van de softwarelaag. Zo kan worden nagegaan of het systeem bestand is tegen een grote belasting.

3.6

Tijdsplanning en feedback

Hieronder volgt de takenplanning in figuur 3.1. De balken geven aan hoeveel weken elke activiteit in beslag neemt en welke activiteiten parallel kunnen worden uitgevoerd. Ook is het de bedoeling dat na elke ‘ticket’ (een taak in de figuur) feedback komt van dan wel de begeleider of de opdrachtgevers. Eveneens kan input gewenst zijn voor we met sommige ‘tickets’ starten, maar dat zullen we dan aangeven. In het diagram zijn de feestdagen niet meegenomen, maar wel in de uitleg die daarna volgt. Plan van aanpak: Voor het plan van aanpak staat een werkweek ingeroosterd, waarvan alleen de eerste 3 dagen iedereen zich hierop kan richten. Het plan van aanpak bevat de informatie over de doelstelling van het project. Verder wordt aandacht besteed aan de projectindeling. Voor het plan van aanpak is ongeveer 80 uur gereserveerd. Literatuuronderzoek: Het literatuuronderzoek naar de keuze van de programmeertaal is geschat op ongeveer 25 uur. Voor het literatuuronderzoek naar API’s van sociale profielen sites en hun authenticatie en autorisatie systemen is 40 uur gereserveerd. Modellen maken: Voor de modellen worden verschillende (sequence, use case en klasse diagram) diagrammen gemaakt. Hier staat totaal 40 uur voor ingeroosterd. Het is belangrijk om veel aandacht te besteden aan deze diagrammen. De reden hiervoor is om eventuele grote problemen van tevoren te voorzien. Documentatiefase af en documentatie ingeleverd: Hier staat zo een 30 uur voor ingepland. Tijdens deze uren moeten verbeteringen van het ingeleverd werk worden verricht en moet er een requirements document en een domein analyse gemaakt worden. Connectie API: De API’s van de verschillende sociale profielensites moeten aangeroepen kunnen worden. Voor elk van de API’s wordt ongeveer 60 uur ingepland. Het kan goed voorkomen dat voor de eerste API meer tijd nodig is dan voor de laatste API. 3

Design by Contract (DbC) omschrijft dat software ontwerpers een formele, precieze en controleerbare interface moeten specifiseren voor software componenten, die de standaard definitie van abstracte datatypes uitbreiden met ‘preconditions’, ‘postconditions’ en ‘invariants’. Deze specificaties worden ‘contracts’ genoemd [3]. Defensive Programming is een form van ‘defensive design’ bedoeld om het continue functioneren van een stuk software te waarborgen, zelfs in onvoorzien gebruik van de software [3].

13

Bij het verbinden met API’s moet er ook al deels rekening gehouden worden met het inloggen. Het proces en het resultaat hiervan wordt gedocumenteerd. Inloggen en database opzetten: De database opzetten en het inloggen, valt volgens de software ontwikkelaars goed te combineren. Hier is 60 uur voor gepland. Hiervan zal de meeste tijd besteedt worden aan het inloggen. Ook hiervan wordt het proces en het resultaat gedocumenteerd. Data uit API’s taggen: De verschillende data die verzameld wordt van de sociale profielensites moet worden gelabeld en deze informatie moet in de database worden geplaatst. Hier staat 40 uur voor in geroosterd. Redundantie verwijderen: Om te voorkomen dat informatie dubbelop wordt opgeslagen, moet er allerlei filters toegepast worden op de verkregen informatie. Aan deze redundantie wordt naar verwachting 40 uur besteed. Koppeling creëren tussen tags en context: Binnen een context moeten er tags geplaatst worden uit de gegeven informatie. Deze tags moeten dus worden gehangen aan stukken informatie. De softwareontwikkelaars verwachten hier veel tijd aan te besteden en hebben er daarom ook 140 uur voor gereserveerd. Afronding koppelingsfase: Er is ook 20 uur gereserveerd voor de koppelingsfase, waarin al het gedocumenteerde wordt doorgenomen en de code van de vorige fase werkend moet worden afgerond. Implementatie GUI: Voor de implementatie van de GUI staat 160 uur gepland. De GUI wordt gemaakt om aan de opdrachtgevers een werkend product te tonen. Hier zullen eventuele bugs worden opgevangen die eerder niet zichtbaar waren. GUI koppelen aan softwarelaag: Het koppelen van de GUI aan de softwarelaag wordt geacht gedaan te kunnen worden binnen 130 uur. Bugs eruit halen: Verder is er nog 60 uur gereserveerd om aan de hand van de tests die uitgevoerd worden de gevonden bugs eruit te halen. Documentatie afronden: Tenslotte is er nog 100 uur gereserveerd om het project af te ronden. Daarbij moet er gedacht worden aan het afronden van de GUI-fase en documentatie van heel het project. Hieronder valt ook het eindverslag. Daarnaast moet er ook nog een presentatie worden voorbereid. Voor het gehele project staat 420 uur per man en dus 1260 uur in totaal. De 14

Tabel 3.1: Sommatie van uren bij taken Taak Plan van aanpak Literatuuronderzoek Modellen maken Documentatiefase af en documentatie ingeleverd Connectie API Inloggen en database opzetten Data uit API’s taggen Redundantie verwijderen Koppeling creeren tussen tags en context Afronden koppelingsfase Implementatie GUI GUI koppelen aan softwarelaag Bugs eruit halen Documentatie afronden Totaal

Aantal Uren 80 60 40 30 300 60 40 40 140 20 160 130 60 100 1260

schatting voor de taken zijn conservatief genomen om eventuele complicaties op te vangen.

15

Figuur 3.1: Gantt chart voor de planning van het project

16

Hoofdstuk 4

Projectinrichting De uitvoerende leden zijn Arvind Mohabir, Koen Boes en Bilal Taouil. De begeleider van TU Delft is Peter van Nieuwenhuizen. De opdrachtgevers en contactpersonen van ntry e-marketing zijn Derrick Stomp en Japser van Blerk. Van de uitvoerende leden wordt verwacht dat ze basiskennis hebben van Java of C#. Ook wordt er verwacht dat er enige ervaring is met HTML en PHP of ASP. Daarnaast moeten de leden in staat zijn om te bepalen welke literatuur bruikbaar is. Als laatste moeten de leden bekend zijn met het proces van het ontwerpen van software. Om het project overzichtelijk te houden wordt gebruik gemaakt van drie hulpmiddelen: SVN, e-mail en Trac. SVN maakt het mogelijk om documentatie en code centraal te houden en overal op te vragen. De e-mail wordt gebruikt om periodiek voortgang bij te houden en deze te laten beoordelen door de begeleider. Ook worden vragen, zo ver mogelijk, over de e-mail afgehandeld. Trac heeft als functie om de voortgang te bekijken en openstaande taken te definiëren. Om voortgang te bespreken is afgesproken om dit met de opdrachtgevers te doen, wanneer de uitvoerende leden op het kantoor van ntry zijn. Daarnaast zullen de opdrachtgevers en begeleider periodiek een tussentijdse versie van het verslag ontvangen. Als het niet mogelijk is om vragen in persoon te stellen, is het mogelijk om te communiceren via Skype of via e-mail. De bespreking met de begeleider is in het EWI-gebouw en zal op afspraak zijn. Vragen bij de begeleider kunnen ook via e-mail gesteld worden. Op het kantoor van ntry is voor de uitvoerende leden een werkkamer aanwezig met een bureau en een white board. De leden moeten zelf een laptop meenemen. Voor de laptops zijn stroomvoorziening en draadloos internet aanwezig. Op TU Delft zijn er computers beschikbaar op de Drebbelweg. Ook is er draadloos internet aanwezig. Een aparte werkplek wordt ook geregeld.

17

18

Hoofdstuk 5

Kwaliteitsborging In deze sectie worden nog een aantal eisen gesteld die, als ze worden nageleefd, de opdrachtgever en de projectleden in staat stelt de kwaliteit van de software te waarborgen. Het is van belang dat de opdrachtgever regelmatig met feedback komt. Aan de hand van de feedback kan dan tijdig worden gezien of er de verkeerde kant op wordt gegaan, met als gevolg dat een hoop dubbel of onnodig werk kan worden voorkomen. Tevens is het van belang dat de opdrachtgevers de verslagen kritisch doornemen. Zo kunnen misverstanden eventueel al aan het licht komen voor de implementatiefase. Om te realiseren wat de opdrachtgevers daadwerkelijk verwachten is het gewenst dat deze het product tussentijds regelmatig beoordelen. Zo kan worden geverifieerd dat het product niet afwijkt van deze verwachtingen. Om frictie later in het project te voorkomen, is het van belang dat alle partijen eerlijk zeggen wat ze van elkaars inzet en de vorderingen tijdens het project vinden. Een bekend probleem tijdens projecten is het ontstaan van een achterstand. We stellen daarom voor om de software incrementeel te ontwerpen opdat het altijd een werkend eind product is i.p.v. een heleboel los staande software die geen samenhangend geheel vormt.

19

Bibliografie [1] LinkedIn, “LinkedIn General User.” http://www.linkedin.com/static? key=advertising_premium, April 2010. [2] T. C. Lethbridge and R. Laganière, Object-Oriented Software Engineering: Practical Software Development using UML and Java. Mc Graw Hill Education, 2 ed., 2005. Literature for the course IN2705 at TU Delft. [3] M. Pezze and M. Young, Software Testing and Analysis: Process, Principles and Techniques. Wiley, 2 ed., 2007. Literature for the course IN3205 at TU Delft.

20

Lijst van figuren 2.1

Het phased-release model, in dit geval met twee fases . . . . . . .

10

3.1

Gantt chart voor de planning van het project . . . . . . . . . . .

16

21

78

Bijlage F

Literatuuronderzoek API’s van verschillende sociale netwerk sites

79

Literatuuronderzoek API’s van verschillende sociale netwerk sites

IN3405 - Bachelor Project van Arvind Mohabir - 1324810 Bilal Taouil - 1303570 Koen Boes - 1314785 ntry e-marketing

24 juni 2010 Version 1.0

Opdrachtgevers en begeleiders: Jasper van Blerk Derrick Stomp Peter van Nieuwenhuizen Universiteit Delft Faculty of Electrical Engineering, Mathematics and Computer Science

Inhoudsopgave 1 Introductie 1.1 Wat is een API . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5 5

2 Service Oriented Architectuur 2.1 Web services en service-oriented architectures . . . . . . . . . . . 2.2 Representational State Transfer . . . . . . . . . . . . . . . . . . .

7 7 8

3 Authenticatie en Autorisatie 11 3.1 OAuth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.2 OpenID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4 Hyves 4.1 API’s . . . . . . 4.2 Authenticatie . . 4.3 Libraries . . . . . 4.3.1 Voorbeeld 4.3.2 Voorbeeld

. . . . . . . . . . . . van de van de

. . . . . . . . . . . . . . . . . . . . . . . . Java ‘library’ C# ‘library’

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

13 13 14 14 15 15

5 Last.fm 5.1 API’s . . . . . . 5.2 Authenticatie . . 5.3 Libraries . . . . . 5.3.1 Voorbeeld 5.3.2 Voorbeeld

. . . . . . . . . . . . van de van de

. . . . . . . . . . . . . . . . . . . . . . . . Java ‘library’ C# ‘library’

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

17 17 18 18 18 19

. . . . .

21 21 22 22 23 23

. . . . .

25 25 28 28 28 28

6 Facebook 6.1 API’s . . . . . . 6.2 Authenticatie . . 6.3 Libraries . . . . . 6.3.1 Voorbeeld 6.3.2 Voorbeeld 7 Twitter 7.1 API’s . . . . . . 7.2 Authenticatie . . 7.3 Libraries . . . . . 7.3.1 Voorbeeld 7.3.2 Voorbeeld

. . . . . . . . . . . . van de van de . . . . . . . . . . . . van de van de

. . . . . . . . . . . . . . . . . . . . . . . . Java ‘library’ C# ‘library’ . . . . . . . . . . . . . . . . . . . . . . . . Java ‘library’ C# ‘library’ 2

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

8 LinkedIn 31 8.1 API’s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 8.2 Authenticatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 8.3 Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 9 Conclusie

35

Bibliografie

37

List of Listings

38

Hoofdstuk 1

Introductie In dit verslag worden de API’s van verschillende sociale profielen sites besproken. Aan elke site wordt één hoofdstuk gewijd. Deze sites zullen respectievelijk Hyves, Last.fm, Facebook, Twitter en LinkedIn zijn. Echter zal eerst wat achtergrond informatie worden behandeld om de daarna volgende hoofdstukken beter in context te kunnen plaatsen. Deze informatie betreft “Service Oriented Architectures” en “Authenticatie en Autorisatie”. Alle sociale profielen sites bieden in ieder geval een RESTful API (, wat RESTful precies inhoud wordt besproken in sectie 2.2). Dit retourneert in de meeste gevallen echter een XML, Json of een gelijke structuur. Echter aangezien er het plan is om in een “Object georiënteerde” programmeertaal te gaan werken zou het handing zijn objecten terug te krijgen, i.p.v. één van de eerder genoemde structuren. Gelukkig betaan er wrappers (libraries) voor de verschillende talen die dit afhandelen. Deze libraries zullen voor elke sociale profielensite respectievelijk worden besproken met bijpassende voorbeelden. In elk hoofdstuk betreffende een sociale profielensite zal ook een kort stukje worden gewijd aan authenticatie en autorisatie. Tenslotte volgt een korte conclusie.

1.1

Wat is een API

Een API is een verzameling definities op basis waarvan een computerprogramma kan communiceren met een ander programma of een onderdeel van een programma (meestal in de vorm van een bibliotheek). Hierdoor kan een tekenprogramma bijvoorbeeld gebruik maken van een afdruk-API in plaats van er zelf één te maken. In dit project moeten er evenementen verzameld worden van contacten. Elk van de vijf sociale profielensites heeft een benaderbare API voor meerdere talen.

5

6

Hoofdstuk 2

Service Oriented Architectuur 2.1

Web services en service-oriented architectures

Web services en service-oriented architectures (SOA) zijn relatief nieuwe technologiën met als doel om software componenten en applicaties toegankelijk te maken met behulp van gestandaardiseerde interfaces. Een web service is een software component dat over het internet beschikbaar is met een gestandaardiseerde interface. Service oriented architectures maken gebruik van web services en moeten voldoen aan zes principes. 1. Elke service is een onafhankelijk programma dat toegankelijk is en geen toestand heeft. 2. De services in een SOA zijn alleen gebonden aan een contract met daarin de invoer, uitvoer, toegankelijkheidsopties, kwaliteitseisen en de verwerking van fouten. 3. Elke service moet te vinden zijn binnen een SOA. 4. Elke service moet aanspreekbaar zijn. 5. Elke service moet bij het wegvallen van de communicatie zelf de verbinding kunnen herstellen. 6. Een gebruiker kan maar in een enkele service tegelijk zijn. Door de gestandaardiseerde interfaces zijn web services onafhankelijk van de implementatie en dus van besturingssystemen en programmeertalen. Dit zorgt voor makkelijker te ontwikkelen gedistribueerde systemen en versimpelde integratie met bestaande software. De technieken worden veel gebruikt op het vlak van integratie met (sterk) verouderde systemen die nog in gebruik zijn en op online handel. Een service provider moet een service hebben geplaatst op een centrale opslagplaats om te kunnen worden gebruikt. Een vragende applicatie kan vervolgens een verzoek sturen naar de server voor een referentie naar de gezochte 7

service. Een standaard die dit proces reguleert is UDDI (Universal Description, Discovery and Integration). Om de service op een consistente manier de berichten op te laten stellen, kan gebruik gemaakt worden van WSDL, Web Service Description Language. WSDL is gebaseerd op XML. De SOAP-standaard (Simple Object Access Protocol) heeft als doel om de service via een afgesproken protocol te versturen van en naar de server. In de praktijk zijn web services een integraal onderdeel van ontwikkelingsmethodes zoals het Microsoft.NET platform en Java EE. Voor scripttalen zoals PHP is het mogelijk om gebruik te maken van web services door middel van beschikbare libraries. Grote bedrijven zoals SAP en Oracle hebben web services een integraal onderdeel gemaakt van hun producten. De publieke, op UDDIgebaseerde servers zijn echter door de grote maatschappijen gesloten. Om dit op te vullen hebben technologie-enthousiasten hun eigen initiatieven opgezet, zoals StrikeIron [1]. Figuur 2.1: Een diagram om aan te geven hoe webservices werken

2.2

Representational State Transfer

Representational State Transfer (REST) is een softwarearchitectuur voor gedistribueerde ‘hypermedia’ systemen zoals het “World Wide Web’. De term ‘RESTful’ wordt gebruikt als er aan de eisen van REST worden voldaan. In tegenstelling tot bijvoorbeeld SOAP is REST geen protocol, dus er zijn geen officiële standaarden voor ‘RESTful’ implementaties. Desondanks kan een ‘RESTful’ implementatie wel gebruik maken van standaarden zoals HTTP, URL, XML, PNG, etc. REST maakt verschil tussen drie klassen van architectonische elementen [2]: • Data elementen; • Connectie-elementen (connectoren); 8

• Verwerkingselementen (components). Roy T. Fielding definieert REST als een gecoördineerde set van architectonische beperkingen die proberen ‘latency’ en netwerkcommunicatie te minimaliseren, terwijl tegelijkertijd wordt geprobeerd de onafhankelijkheid en schaalbaarheid van componentimplementaties te maximaliseren. REST staat het toe interacties te ‘cachen’ en hergebruiken, componenten dynamisch te substitueren en acties door ‘tussenpersonen’ te verwerken. Hierdoor wordt aan de behoeften van een ‘Internet-scale’ gedistribueerd ‘hypermedia’ systeem voldaan. [3] Belangrijke doelen van REST zijn dus: • Het bevorderen van de schaalbaarheid; • Het generaliseren van interfaces; • Het onafhankelijk inzetten van componenten; • Het mogelijk maken om gebruik te maken van tussencomponenten met als doel: – Het verlagen van ‘latency’; – De veiligheid beter waarborgen; – Het incapsuleren van ‘legacy’ systemen.

9

10

Hoofdstuk 3

Authenticatie en Autorisatie Om veiligheid te waarborgen is een vorm van authenticatie nodig. Een site moet een methode hebben om een gebruiker te kunnen identificeren. De meest voorkomende methodes die voorkomen dat de gebruiker bij elke site handmatig moet inloggen zijn OpenID en Oauth.

3.1

OAuth

Wanneer een site er voor kiest om OAuth te gebruiken, wordt door de site en gebruiker een privé en publieke identificatiesleutel opgesteld. Met deze sleutel kan de softwarelaag een veilige verbinding maken met een API. Een goed voorbeeld dat gebruikt kan worden om OAuth uit te leggen is het geval waarin een gebruiker een foto wil uitprinten die is opgeslagen op een andere site. De interactie hierbij gaat ongeveer als volgt: de gebruiker logt in bij de printer website en plaatst een bestelling voor een afdruk. De printer website vraagt welke foto’s te printen en de gebruiker kiest voor de naam van de site waar haar foto’s zijn. De printer website stuurt de gebruiker naar de foto-site om toegang te verlenen. Op de fotosite van de gebruiker logt de gebruiker zich in met haar account en wordt gevraagd of ze echt haar foto’s wil delen met de printer website. Als zij ermee instemt, wordt ze teruggestuurd naar de printer site, die nu toegang heeft tot de foto’s. De gebruiker heeft nu dus toegang verkregen tot de fotosite vanuit de printerwebsite zonder haar gebruikersnaam en wachtwoord te geven aan de printersite. De softwarelaag moet er dus voor zorgen - indien er OAuth gebruikt gaat worden - dat de gebruiker eerst wordt geauthenticeerd op de sociale profielensite door daar in te loggen. Vervolgens wordt er dan toegang verleend aan de softwarelaag van de sociale profielensite. Groot voordeel hiervan is dat er niet ingelogd hoeft te worden met een gebruikersnaam of wachtwoord van de sociale profielensite bij de softwarelaag. 11

3.2

OpenID

Met OpenID wordt je wachtwoord en gebruikersnaam gegeven aan jouw identiteit provider en die provider bevestigt vervolgens jouw identiteit aan websites die je bezoekt. Behalve je provider ziet niemand je wachtwoord. Grote organisaties zoals Google, Facebook en Microsoft gebruiken het. OpenID heeft geen eigenaar en iedereen is in staat om zijn eigen identiteit provider te starten. De OpenID provider geeft de gebruiker een URL om zich bij de verschillende websites te authenticeren. Groot voordeel van OpenID is dat je eenmaal hoeft in te loggen om bij meerdere websites in te loggen.

12

Hoofdstuk 4

Hyves 4.1

API’s

De Hyves API is gebouwd volgens de REST-achitectuur. Alle aanroepen naar deze API moeten naar ‘URL root’, “data.hyves-api.nl”, worden gedaan. Parameters naar de API moeten worden meegestuurd in de ‘POST body’ van een ‘HTTP request’ (url geëncodeerd) of in de ‘query’ string. De OAuth parameters kunnen worden verstuurd in de ‘Authorization-HTTPheader’. Als ‘auth’ methodes worden gebruikt worden alleen HTTPS aanroepen geaccepteerd. Het resultaat kan worden geretourneerd in vier verschillende formaten: XML, JSON, XMLP, JSONP. Hyves accepteert alleen HTTP 1.1 aanroepen, HTTP 1.0 aanroepen retourneren een ‘exception’. Aanroepen moeten GET of POST ‘HTTP requests’ zijn. De precieze parameters die benodigd zijn om API aanroepen te doen zijn te vinden in de HyvesConnect ontwikkelaar documentatie [4], evenals de informatie hierboven. Hier volgt één instantie van een voorbeeld van een Hyves API aanroep. De hieronder staande link is een voorbeeld van een Hyves API aanroep voor het verkrijgen van een ‘event’ naar ‘id’. In een dergelijke aanroep is het bijvoorbeeld ook mogelijk meerdere instanties ineens op te vragen. In dit geval door meerdere ‘event id’s’ op te geven, gescheiden door een komma. In listing 4.1 is het geretourneerde resultaat weergegeven. http://data.hyves-api.nl/?eventid=00eeb26c68e883d8dd43a2a3eb8a28fec4&ha_ method=events.get&oauth_consumer_key=Nl-SK2c5ZCBKB_I8hCF_ zjPd&oauth_timestamp=1269608395&ha_version=2.0&oauth_signature_ method=HMAC-SHA1&ha_format=xml&ha_fancylayout=false&oauth_ nonce=530174_176&oauth_signature=h8ULP3XhC7kJ0F%2F7%2FNuD60vtNb8% 3D

13



Listing 4.1: Resultaat van een Hyves API aanroep om een lijst van ‘events’ naar ‘eventid’ 1 2 3 4

5 6 7

8

9 10 11 12 13 14 15 16 17 18 19

20

21

22 23

<e v e n t s _ g e t _ r e s u l t> <e v e n t> <e v e n t i d>00 e e b 2 6 c 6 8 e 8 8 3 d 8 d d 4 3 a 2 a 3 e b 8 a 2 8 f e c 4 < t i t l e>Hyves API b e t a Hyves API b e t a r e l e a s e . 006 f 5 6 9 d a 8 e e b 8 4 d 0 4 0 c 8 4 d b 5 9 1 a 6 9 e 4 1 3 h t t p : //yme−bosma . hyves . n l / e v e n t s /1270243/ Hyves_API_beta/ <s t a r t d a t e>1199350800 <enddate>1199350800 f a l s e 15 < c i t y i d /> < v i s i b i l i t y>hub 1194453601 0 77 <s e c u r e _ c o n n e c t i o n> f a l s e

4.2

Authenticatie

De Hyves API maakt gebruik van OAuth om een gebruiker te authenticeren, een ‘request’ te onder tekenen, ‘replay attacks’ te blokkeren en gebruikers toe te staan om aanroepen te doen als een specifieke gebruiker. De hyves-API is compleet verenigbaar met de OAuth 1.0 specificatie.

4.3

Libraries

Momenteel ondersteunt Hyves nog geen ‘libraries’. Echter zijn er wel enkele officieuse ‘libraries’ beschikbaar. In tabel 4.1 zijn er een aantal weergegeven. In sectie 4.3.1 en 4.3.2 volgen voorbeelden voor respectievelijk Java en C#. 14

Tabel 4.1: Een aantal beschikbare ‘libraries’ voor de Hyves API Naam Taal PHP Flash/ActionScript Java Javascript C#.NET GenusApis X X Doyourthing X AS3Hyves X Hyves4j X Bee.NET X Ruby wrapper

4.3.1

Ruby

X

Voorbeeld van de Java ‘library’

In dit voorbeeld zal de Hyves4j library [5] worden gebruikt als de Java library. De algemene aanpak voor het werken met de Hyves4j library is als volgt: 1. Creëer en configureer een nieuwe “H4jClient”. 2. Gebruik deze om een nieuwe instantie van Hyves4j te creëren. 3. Vraag de Hyves4j instantie om een API ‘interface’, zoals ‘Users’ of ‘Media’. 4. Gebruik de ‘public’ methodes van deze interface om gegevens te verkrijgen van de ‘Hyves-api’ in de vorm van domein klassen (com.spikylee.hyves4j.model). De meest simpele manier om een nieuwe (anonieme) Hyves4J instantie te creëren is te zien in listing 4.2. Vervolgens kan deze worden aangeroepen om informatie te verkrijgen, in dit geval gebruikers en vervolgens de voor- en achternamen. 

Listing 4.2: Voorbeeld van de Hyves4j library 1 2 3 4

Hyves4j h 4 j = new Hyves4j ( ) ; H4jUsers u s e r s = h 4 j . g e t U s e r s ( ) ; User u s e r = u s e r s . getByUsername ( " s p i k y l e e " ) ; System . out . p r i n t l n ( " R e t r i e v e d u s e r " + u s e r . getFirstName ( ) + " " + u s e r . getLastName ( ) ) ;

4.3.2

Voorbeeld van de C# ‘library’

In dit voorbeeld zal de Bee.NET library [6] worden gebruikt als de C# library. De algemene aanpak voor het werken met de Bee.NET library is als volgt: Stap één - Pas het bestand web.config aan Begin met het toevoegen van de, in listing 4.3 weergegeven, sectie aan de “configSections” en voeg het tweede stuk toe achter de system.web sluit ‘tags’. 

Listing 4.3: Voorbeeld van de Bee.NET library configuration 1 2 3

... 15

4

5 6 7 8 9 10 11

12 13

...

<s e c t i o n name=" hyves " type=" Hyves . Web . C o n f i g u r a t i o n . HyvesSection , HyvesNET . Web" a l l o w D e f i n i t i o n=" MachineToApplication " r e q u i r e P e r m i s s i o n=" f a l s e "/>

... " c o n s u m e r S e c r e t=""/> ...

Stap twee - Voeg de ‘HyvesApplication-control’ toe 

Voeg een nieuw ‘web form’ aan uw project toe of pas de huidige aan. Voeg het volgende stukje code toe: 1

Verzeker u zelf er van dat de ‘ApplicationName’ het zelfde is als degene gebruikt in het web.config bestand. Stap drie - Gebruik de ‘HyvesApplication-control’ om gegevens op te vragen In listings 4.4 staat een voorbeeld voor het gebruik van de ‘HyvesApplicationcontrol’. Deze kan worden aangeroepen om informatie te verkrijgen, in dit geval de aangemelde gebruiker om vervolgens zijn voor- en achternamen op te vragen.



Listing 4.4: Voorbeeld het gebruik van de Bee.NET library code 1

2 3

Hyves . S e r v i c e . User u s e r = h y v e s A p p l i c a t i o n . S e r v i c e . U s e r s . GetLoggedinUser ( ) ; f i r s t n a m e L i n k . Text = u s e r . Firstname ; f i r s t n a m e L i n k . N a v i g a t e U r l = u s e r . Url ;

16

Hoofdstuk 5

Last.fm 5.1

API’s

De Last.fm API staat toe methodes aan te roepen in een REST stijl XML. De API ‘root URL’ is “http://ws.audioscrobbler.com/2.0/”. Methode parameters, uitgedrukt als ‘package.method’, samen met methode specifieke argumenten worden naar de ‘URL root’ gestuurd. De API ondersteunt meerdere transport formaten, maar reageert standaard in Last.fm idioom XML. Het is echter wel van belang UTF-8 encodering te gebruiken voor argumenten die bij API methodes horen.[7] De hieronder staande link is een voorbeeld van een aanroep naar de ‘API root’. In listing 5.1 is een resultaat weergegeven, om een beeld te geven wat de structuur van zo’n resultaat is. http://ws.audioscrobbler.com/2.0/?method=artist.getSimilar&api_ key=xxx... 

Listing 5.1: Resultaat van een Last.fm API aanroep 1 2 3

4

5

6 7 8 9 10 11 12 13 14

< r e s u l t s f o r=" d i s c o " x m l n s : o p e n s e a r c h=" h t t p : // a9 . com/−/ s p e c / o p e n s e a r c h / 1 . 1 / "> 2641 0 20 d i s c o 55483 www. l a s t . fm/ t a g / d i s c o ... 17

15 16 17 18 19 20 21 22

d i s c o pop 160 www. l a s t . fm/ t a g / d i s c o %20pop

5.2

Authenticatie

De authenticatie API biedt derden een veilige manier om een Last.fm gebruikerssessie te creëren over de Last.fm API. Alle schrijf diensten vereisen authenticatie. Het is benodigd een ‘API key’ aan te vragen, alvorens authenticeren mogelijk is.

5.3

Libraries

Momenteel ondersteunt Last.fm nog geen ‘libraries’. Echter zijn er wel enkele officieuse ‘libraries beschikbaar. In tabel 5.1 zijn er een aantal weergegeven. In sectie 5.3.1 en 5.3.2 volgen voorbeelden voor respectievelijk Java en C#.

5.3.1

Voorbeeld van de Java ‘library’

In dit voorbeeld zal de “Last.fm API bindings for Java” library [8] worden gebruikt als de Java library. De “Last.fm API bindings for Java” library biedt klasses en methodes om de Last.fm API aan te roepen. Een voorbeeld van bron code om een gebruikers wekelijkse top 10 van artiesten op te vragen is weergegeven in listing 5.2.

Tabel 5.1: Een aantal beschikbare ‘libraries’ voor de Last.fm API Taal Library(ies) Qt C++ Liblastfm Java Last.fm API Java Bindings .NET LastFmLib.Net Python pyLast Ruby scrobbler2 PHP PHP Last.fm API / Felix Brun’s PHP libs Actionscript Lastfm-as3 C# Last.fm# Perl Net::LastFM Javascript Felix Brun’s Javascript libs Objective-C FMEngine 18



Listing 5.2: Voorbeeld van de “Last.fm API bindings for Java” library 1

2 3

4 5 6 7

8 9 10 11

S t r i n g key = " b25b959554ed76058ac220b7b2e0a026 " ; // t h i s i s t h e key used i n t h e l a s t . fm API e x a m p l e s o n l i n e . S t r i n g u s e r = " JRoar " ; Chart c h a r t = User . g e t W e e k l y A r t i s t C h a r t ( u s e r , 1 0 , key ) ; DateFormat format = DateFormat . g e t D a t e I n s t a n c e ( ) ; S t r i n g from = format . format ( c h a r t . getFrom ( ) ) ; S t r i n g t o = format . format ( c h a r t . getTo ( ) ) ; System . out . p r i n t f ( " Charts f o r %s f o r t h e week from %s t o %s :%n " , u s e r , from , t o ) ; C o l l e c t i o n a r t i s t s = c h a r t . g e t E n t r i e s ( ) ; f or ( A r t i s t a r t i s t : a r t i s t s ) { System . out . p r i n t l n ( a r t i s t . getName ( ) ) ; }

5.3.2

Voorbeeld van de C# ‘library’

In dit voorbeeld zal de “Last.fm#” library [9] worden gebruikt als de C# library. De “Last.fm#” library biedt klasses en methodes om de Last.fm API aan te roepen. Een voorbeeld van bron code, voor het authenticeren, is weergegeven in listing 5.3. 

Listing 5.3: Voorbeeld van het gebruik van de Last.fm# library code 1 2 3 4 5 6 7 8 9

10

11

12

13 14

15 16 17 18 19 20

u s i n g System ; u s i n g Lastfm . S e r v i c e s ; namespace MyApp { c l a s s MainClass { p u b l i c s t a t i c v o i d Main ( s t r i n g [ ] a r g s ) { // Get your own API_KEY and API_SECRET from h t t p : / / www. l a s t . fm/ a p i / a c c o u n t s t r i n g API_KEY = " b25b959554ed76058ac220b7b2e0a026 "; s t r i n g API_SECRET = " 361505 f8eeaf61426ef95a4317482251 " ; // C r e a t i n g an u n a u t h e n t i c a t e d s e s s i o n t h a t c o u l d o n l y a l l o w me // t o perform r e a d o p e r a t i o n s . S e s s i o n s e s s i o n = new S e s s i o n (API_KEY, API_SECRET) ; C o n s o l e . WriteLine ( " P l e a s e e n t e r your username : " ) ; s t r i n g username = C o n s ol e . ReadLine ( ) ; C o n s o l e . WriteLine ( " P l e a s e e n t e r your password : " ) ; 19

s t r i n g md5password = Lastfm . U t i l i t i e s . md5( C o n s o le . ReadLine ( ) ) ;

21

22

// A u t h e n t i c a t e i t with a username and password t o be a b l e // t o perform w r i t e o p e r a t i o n s and a c c e s s t h i s u s e r ’ s profile // p r i v a t e data . s e s s i o n . A u t h e n t i c a t e ( username , md5password ) ;

23

24

25 26 27 28

29 30 31

}

}

}

// You can now u s e t h e " s e s s i o n " o b j e c t with e v e r y t h i n g i n your p r o j e c t .

20

Hoofdstuk 6

Facebook 6.1

API’s

De Facebook API maakt gebruik van een soort REST ‘interface’. Dit betekent dat Facebook methode-aanroepen, over het internet, gedaan worden door het zenden van HTTP GET en POST ‘requests’ naar de Facebook API REST server (http://api.facebook.com/restserver.php). De nieuwste Facebook API heet de “Graph API” en maakt het makkelijker om gegevens te lezen van en te schrijven naar Facebook. De API presenteert de Facebook ‘social graph’. Tevens representeert het objecten in deze graaf op een uniforme manier (zoals personen, foto’s, gebeurtenissen en fan pagina’s) en de connecties tussen deze objecten (zoals vriendschappen, gedeelde gegevens en foto tags). Elk object in de ‘social graph’ heeft een uniek ID. Data geassocieerd met een object kan worden verkregen door een aanroep als “https://graph.facebook. com/ID” te doen. Het is ook mogelijk personen en pagina’s op te vragen aan de hand van gebruikersnamen. Alle objecten in de Facebook ‘social graph’ zijn verbonden met elkaar via een relatie. In de API worden deze relatie connecties genoemd. Je kunt deze relatie connecties op vragen door een URL van de vorm “https://graph.facebook. com/ID/CONNECTION_TYPE” te gebruiken. Alle resultaten zijn JSON objecten.[10] De onderstaande links zijn twee indentieke API aan roepen, listing 6.1 geeft het geretourneerde JSON object weer. https://graph.facebook.com/19292868552 https://graph.facebook.com/platform 

Listing 6.1: Resultaat van een Facebook API aanroep 1 2 3 4

5

{

" id " : "19292868552" , " name " : " Facebook P l a t f o r m " , " p i c t u r e " : " h t t p : / / p r o f i l e . ak . fbcdn . n e t / o b j e c t 3 /1566/8/ s19292868552_1660 . j p g " , " l i n k " : " h t t p : / /www. f a c e b o o k . com/ p l a t f o r m " , 21

6 7 8 9

10 11

12 13

}

" c a t e g o r y " : " Technology " , " username " : " p l a t f o r m " , " founded " : "May 2 0 0 7 " , " company_overview " : " Facebook P l a t f o r m e n a b l e s anyone t o b u i l d s o c i a l a p p l i c a t i o n s on Facebook and t h e web . " , " m i s s i o n " : " To make t h e web more open and s o c i a l . " , " p r o d u c t s " : " Facebook A p p l i c a t i o n Programming I n t e r f a c e ( API ) \ nFacebook Query Language (FQL) \ nFacebook Markup Language (FBML) \ nFacebook J a v a S c r i p t (FBJS) \ nFacebook Connect \n " , " fan_count " : 453541

Facebook bied ook een ander soort API, namelijk de “Facebook Query Language” (FQL). Deze API maakt het mogelijk gegevens, uit de ‘social graph’ te queriën d.m.v. een SQL-achtige ‘interface’. Deze methode biedt enkele extra mogelijkheden die de “Graph API” niet biedt. FQL queries kunnen worden uitgevoerd door links te gebruiken als, “https: //api.facebook.com/method/fql.query?query=QUERY”. Queries zijn van de vorm “SELECT [fields] FROM [table] WHERE [conditions]” Resultaten kunnen zowel in JSON als in XML worden geretourneerd.

6.2

Authenticatie

Facebook gebruikt het OAuth 2.0 protocol voor authenticatie en authorisatie. Als een Facebook gebruiker een applicatie authoriseert, dan heeft deze toegang tot de gebruiker zijn Facebook ID. Standaard kan een applicatie alle publieke gegevens in een gebruikersprofiel opvragen. Dit omvat de naam, profiel foto, geslacht en de vrienden lijst. Als een applicatie ook andere informatie wil kunnen benaderen, die mogelijk privé is, dan kan er permissie worden aangevraagd.

6.3

Libraries

Momenteel ondersteunt Facebook enkel de in tabel 6.1 genoemde ‘libraries’. Voor Java is de officieuse “facebook-java-api” beschikbaar. In sectie 6.3.1 en 6.3.2 volgen voorbeelden voor respectievelijk Java en C#.

Tabel 6.1: Een aantal beschikbare ‘libraries’ voor de Facebook API Taal Library(ies) .NET Facebook .NET SDK PHP Facebook PHP SDK Actionscript Facebook ActionScript 3.0 Client Library Javascript Facebook JavaScript client library Objective-C Facebook iPhone SDK 22

6.3.1

Voorbeeld van de Java ‘library’

In dit voorbeeld zal de “facebook-java-api” library [11] worden gebruikt als de Java library. De “facebook-java-api” library biedt klassen en methodes om de Facebook API aan te roepen. Het is mogelijk resultaten in verschillende representaties terug te krijgen, deze zijn Json, XML en Jaxb. Een simpel voorbeeld om een gebruiker zijn vrienden op te vragen is weergegeven in listing 6.2. 

Listing 6.2: Voorbeeld van de “facebook-java-api” library 1

2

F a c e b o o k J s o n R e s t C l i e n t c l i e n t = new F a c e b o o k J s o n R e s t C l i e n t ( " apiKey " , " s e c r e t K e y " , " sessionId " ) ; JSONArray r e s p o n s e = ( JSONArray ) c l i e n t . f r i e n d s _ g e t ( ) ;

6.3.2

Voorbeeld van de C# ‘library’

In dit voorbeeld zal de “Facebook .NET SDK” library [12] worden gebruikt als de C# library. De “Facebook .NET SDK” library biedt klassen en methodes om de Facebook API aan te roepen. Een simpel voorbeeld om een gebruiker zijn vrienden op te vragen is weergegeven in listing 6.3. 

Listing 6.3: Voorbeeld van het gebruik van de “Facebook .NET SDK” library code 1 2 3

4

5 6 7 8 9

10 11 12 13 14

15 16 17

18 19

p u b l i c C o l l e c t i o n <User> G e t O n l i n e F r i e n d s ( ) { C o l l e c t i o n <s t r i n g > o n l i n e F r i e n d s = G e t O n l i n e F r i e n d I d s () ; return GetUserInfo ( StringHelper . ConvertToCommaSeparated ( o n l i n e F r i e n d s ) ) ; } p u b l i c C o l l e c t i o n <s t r i n g > G e t O n l i n e F r i e n d I d s ( ) { C o l l e c t i o n <s t r i n g > f r i e n d L i s t = new C o l l e c t i o n <s t r i n g >() ; s t r i n g xml = GetOnlineFriendsXML ( ) ; i f ( ! S t r i n g . IsNullOrEmpty ( xml ) ) { XmlDocument xmlDocument = LoadXMLDocument ( xml ) ; XmlNodeList n o d e L i s t = xmlDocument . GetElementsByTagName ( " f q l _ q u e r y _ r e s p o n s e " ) ; i f ( n o d e L i s t != n u l l && n o d e L i s t . Count > 0 ) { XmlNodeList r e s u l t s = xmlDocument . GetElementsByTagName ( " u s e r " ) ; foreach ( XmlNode node i n r e s u l t s ) { 23

20

21 22

}

23 24 25 26 27 28 29

30

}

return f r i e n d L i s t ;

i f ( ! s t r i n g . IsNullOrEmpty ( _userId ) ) { p a r a m e t e r L i s t . Add( " query " , S t r i n g . Format ( C u l t u r e I n f o . I n v a r i a n t C u l t u r e , " {0}{1}{2} " , "SELECT u i d FROM u s e r WHERE u i d IN (SELECT u i d 2 FROM f r i e n d WHERE u i d 1=" , _userId , " ) AND ’ a c t i v e ’ IN online_presence " ) ) ;

32 33 34 35

36

37

} else {

38 39 40 41

42

44

}

p u b l i c s t r i n g GetOnlineFriendsXML ( ) { D i c t i o n a r y <s t r i n g , s t r i n g > p a r a m e t e r L i s t = new D i c t i o n a r y <s t r i n g , s t r i n g >(3) ; p a r a m e t e r L i s t . Add( " method " , " f a c e b o o k . f q l . query " ) ;

31

43

}

f r i e n d L i s t . Add( XmlHelper . GetNodeText ( node , " uid " ) ) ;

}

throw new FacebookException ( " User Id i s r e q u i r e d " ) ;

} return ExecuteApiCallString ( parameterList , true ) ;

24

Hoofdstuk 7

Twitter 7.1

API’s

De Twitter API is gebouwd volgens de REST-achitectuur. Alle aanroepen naar deze API moeten naar ‘URL root’, “http://api.twitter.com/1/”, worden gedaan. Aanroepen moeten GET of POST ‘HTTP requests’ zijn. Het resultaat kan worden geretourneerd in vier verschillende formaten: XML, JSON, RSS, ATOM. Het is ook van belang UTF-8 encodering te gebruiken voor argumenten die bij API methodes horen. Er kunnen echter slechts een beperkt aantal aanroepen per tijdseenheid naar de Twitter API worden gedaan. De precieze parameters die benodigd zijn om API aanroepen te doen zijn te vinden in de “Twitter API wiki” documentatie [13], evenals de informatie hierboven. Hier volgt één instantie van een voorbeeld van een Twitter API aanroep. De hieronder staande link is een voorbeeld van een Twitter API aanroep voor het verkrijgen van de twintig meest recente statussen van onbeschermde gebruikers die een ‘custom’ gebruikers icoon hebben ingesteld. In listing 7.1 is het geretourneerde resultaat weergegeven. http://api.twitter.com/1/statuses/public_timeline.format

25



Listing 7.1: Resultaat van een Twitter API aanroep 1 2 3 4 5 6 7 8 9

10 11

12 13

14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35

36 37

38 39 40 41

<s t a t u s e s> <s t a t u s> Tue Apr 07 22 : 5 2 : 5 1 +0000 2009 1472669360 At l e a s t I can g e t your humor through t w e e t s . RT @abdur: I don ’ t mean t h i s i n a bad way , but g e n e t i c a l l y s p e a k i n g your a c u l −de−s a c . <s o u r c e>&l t ; a h r e f =" h t t p : //www. t w e e t d e c k . com/">TweetDeck& l t ; / a> f a l s e f a l s e 1401881 Doug Williams <screen_name>dougw San F r a n c i s c o , CA T w i t t e r API Support . I n t e r n e t , greed , u s e r s , dougw and o p p o r t u n i t i e s a r e my p a s s i o n s .

h t t p : // s 3 . amazonaws . com/ t w i t t e r _ p r o d u c t i o n / p r o f i l e _ i m a g e s /59648642/ avatar_normal . png

h t t p : //www. i g u d o . com

f a l s e

26

42 43 44 45

46 47 48 49 50 51

52 53

54 55 56 57 58 59 60 61 62 63 64 65

66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85

1027

9ae4e8

000000

0000 f f

e 0 f f 9 2

87bc44 293 Sun Mar 18 06 : 4 2 : 2 6 +0000 2007 0 −18000 E a s t e r n Time (US & Canada ) <profile_background_image_url >h t t p : // s 3 . amazonaws . com/ t w i t t e r _ p r o d u c t i o n / p r o f i l e _ b a c k g r o u n d _ i m a g e s /2752608/ t w i t t e r _ b g _ g r a s s . jpg

f a l s e

<s t a t u s e s _ c o u n t >3390 < n o t i f i c a t i o n s >f a l s e f a l s e t r u e . . . truncated . . .

27

7.2

Authenticatie

De REST API bevat een aantal methodes die authenticatie vereisen. Bijvoorbeeld methodes die alleen bedoeld zijn voor ingelogte gebruikers, zoals het ‘updaten’ of ‘downloaden’ van ‘direct messages’. Sinds begin 2009 is het OAuth ‘pattern’ voor authenticeren volledig geintregreerd in de REST API. ‘Access tokens’ verlopen nooit. Een gebruikers ‘access token’ verloopt slechts als deze door de gebruiker wordt opgeheven. Er kan verschil worden gemaakt tussen Read-Only or Read-Write access.

7.3

Libraries

Er zijn veel libraries beschikbaar als wrapper voor de Twitter API, om het overzichtelijk te houden zullen we in deze tekst er slechts twee aanhalen. Deze zullen er één voor Java en één voor C# zijn, respectievelijk Twitter4J en TweetSharp. In sectie 7.3.1 en 7.3.2 volgen voorbeelden voor respectievelijk Java en C#.

7.3.1

Voorbeeld van de Java ‘library’

In dit voorbeeld zal de “Twitter4J” library [14] worden gebruikt als de Java library, het is echter wel een officieuse library. De “Twitter4J” library biedt klasses en methodes om de Twitter API aan te roepen. Een voorbeeld van bron code, voor het opvragen van een “vrienden tijdlijn”, is weergegeven in listing 7.2. 

Listing 7.2: Voorbeeld van de “Twitter4J” library 1 2

3

4 5 6

7 8

// The f a c t o r y i n s t a n c e i s re−u s e a b l e and t h r e a d s a f e . T w i t t e r t w i t t e r = new T w i t t e r F a c t o r y ( ) . g e t I n s t a n c e ( twitterID , twitterPassword ) ; L i s t <S t a t u s > s t a t u s e s = t w i t t e r . getFriendsTimeline () ; System . out . p r i n t l n ( " Showing f r i e n d s t i m e l i n e . " ) ; for ( Status s t a t u s : s t a t u s e s ) { System . out . p r i n t l n ( s t a t u s . g e t U s e r ( ) . getName ( ) + " :" + s t a t u s . getText ( ) ) ; }

7.3.2

Voorbeeld van de C# ‘library’

In dit voorbeeld zal de “TweetSharp” library [15] worden gebruikt als de C# library, het is echter wel een officieuse library. De “TweetSharp” library biedt klassen en methodes om de Twitter API aan te roepen. Een voorbeeld van bron code, voor het opvragen van een “tijdlijn”, is weergegeven in listing 7.3. 

Listing 7.3: Voorbeeld van de “TweetSharp” library 1

u s i n g Dimebrain . TweetSharp . F l u e n t ; 28

2 3 4 5

6

7 8 9 10 11 12

u s i n g Dimebrain . TweetSharp . E x t e n s i o n s ; u s i n g Dimebrain . TweetSharp . Model ; // Get t h e p u b l i c t i m e l i n e , c a c h i n g t h e r e s u l t f o r two minutes var t w i t t e r = F l u e n t T w i t t e r . C r e a t e R e q u e s t ( ) . C o n f i g u r a t i o n . CacheUntil ( 2 . Minutes ( ) . FromNow ( ) ) . S t a t u s e s ( ) . OnPublicTimeline ( ) . AsJson ( ) ; // Get r e s p o n s e from T w i t t e r var r e s p o n s e = t w i t t e r . Request ( ) ; // Convert r e s p o n s e t o data c l a s s e s var t w e e t s = r e s p o n s e . A s S t a t u s e s ( ) ;

29

30

Hoofdstuk 8

LinkedIn 8.1

API’s

De LinkedIn API staat toe methodes aan te roepen in een REST stijl XML. De API ‘root URL’ is “http://api.linkedin.com/v1/people”. Methode parameters en argumenten, uitgedrukt als ‘key=value’ paren, worden naar de ‘URL root’ gestuurd. [16] De hieronder staande link is een voorbeeld van een aanroep naar de ‘API root’. In listing 8.1 is een resultaat weergegeven, om een beeld te geven wat de structuur van zo’n resultaat is. http://api.linkedin.com/v1/people/id=abcdefg 

Listing 8.1: Resultaat van een LinkedIn API aanroep 1 2 3 4 5 6 7 8 9

10 11 12 13 14 15 16 17 18 19 20 21

< f i r s t −name> <summary/>

31

22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52

< t i t l e> <summary> <s t a r t −d a t e> <month> <member−u r l −r e s o u r c e s> <member−u r l> <s i t e −standard −p r o f i l e −r e q u e s t>



8.2

Authenticatie

De LinkedIn API gebruikt OAuth als authenticatie methode. LinkedIn vereist een gebruikers ‘login’. De reden hiervoor is dat de meeste gebruikersdata gepresenteerd is vanuit de eindgebruiker zijn perspectief. Daarom is het van belang te weten wie de informatie opvraagt. Hetzelfde geldt voor de API’s. Verder geldt om privacy redenen dat er enkel informatie van gebruikers kan worden opgevraagd als deze daar toestemming voor heeft gegeven.

8.3

Libraries

Tot dusver zijn er voor LinkedIn nog geen libraries beschikbaar. Dit komt door de volgende restrictie die LinkedIn ontwikkelaars oplegt: You cannot provide API access to your customers You can certainly provide the data you receive through the APIs, but you 32

cannot provide use of the LinkedIn APIs as a feature of your product. This applies mainly to platforms that want to wrap the LinkedIn APIs. LinkedIn needs to have a direct relationship with any application making API calls. Data Storage and Conversion You may not store or cache any Content returned or received through the APIs, including data about users, longer than the current usage session of the user for which it was obtained, except for the alphanumeric user IDs we provide you for identifying users, unless and to the extent that such storage or caching is expressly allowed in the Platform Guidelines. You may store the alphanumeric user IDs we provide you indefinitely unless we terminate your use of the APIs for breach of these Terms. The restrictions of this Section do not apply to “Independent Data”, which means data that users provide directly to you, provided that you cannot convert data received from the APIs to Independent Data (e.g., by obtaining it from the APIs and asking the user for permission); Independent Data must have been separately entered, uploaded, or presented to you by the user of your Application.

33

34

Hoofdstuk 9

Conclusie Uit de voorgaande hoofdstukken volgt dat er voor elk van de onderzochte social profielen sites in ieder geval een RESTful API beschikbaar is. Tevens zijn voor alle API’s, behalve één, libraries voor verschillende talen beschikbaar, die de informatie in objecten retourneert i.p.v. een plaintext formaat. Voor de talen Java en C# zijn verschillende libraries behandeld. Voor beide talen bestaan er evenveel officiele als officieuse libraries. Veel libraries voor C# worden echter door Microsoft onderhouden. Dit maakt de kans dat deze goed worden onderhouden en lang worden ondersteund groter. LinkedIn is echter een uitzondering. Hun stricte gebruiksvoorwaarden voorkomen dat het mogelijk is een library voor hun API te schrijven. Het is echter wel mogelijk gegevens op te vragen en op te slaan met expliciete toestemming van een betreffende gebruiker. Alle onderzochte profielensites maken gebruik van OAuth voor authenticatie en autorisatie.

35

36

Bibliografie [1] D. Fensel, Enabling Semantic Web Services. Springer Berlin Heidelberg, 2007. Chapter 4 Web Services. [2] M. Jakl, “Rest: Representational state transfer.” University of Technology Vienna, 2006. [3] R. T. Fielding and R. N. Taylor, “Principled design of the modern web architecture,” ACM Trans. Inter. Tech., vol. 2, no. 2, pp. 115–150, 2002. [4] Hyves, “HyvesConnect developer hyves-api.nl, April 2010.

documentation.”

http://trac.

[5] spikylee, “Hyves4J.” http://code.google.com/p/hyves4j/, April 2010. [6] A. Geertsema, “Bee.NET.” http://beenet.codeplex.com/, April 2010. [7] Last.fm, “Last.fm Web Services.” http://www.last.fm/api, April 2010. [8] J. Kovacs, “Last.fm API bindings for Java.” http://www.u-mass.de/ lastfm, April 2010. [9] A. Hassan, “lastfm-sharp.” http://code.google.com/p/lastfm-sharp/, April 2010. [10] Facebook, “Facebook Developers.” http://developers.facebook.com/, April 2010. [11] D. J. Boden, “facebook-java-api: A Facebook API client implemented in Java, originally derived from the official Facebook client..” http://code. google.com/p/facebook-java-api/, April 2010. [12] Microsoft, “Microsoft SDK for Facebook Platform.” http://wiki. developers.facebook.com/index.php/Microsoft_SDK_for_Facebook_ Platform, April 2010. [13] Twitter, “Twitter API wiki.” http://apiwiki.twitter.com/, April 2010. [14] Y. Yamamoto, April 2010.

“Twitter4J.” http://twitter4j.org/en/index.html,

[15] TweetSharp, “TweetSharp.” http://tweetsharp.com/, April 2010. [16] LinkedIn, “LinkedIn Developer Network.” http://developer.linkedin. com/community/apis, April 2010.

37

Listings 4.1 4.2 4.3 4.4 5.1 5.2 5.3 6.1 6.2 6.3 7.1 7.2 7.3 8.1

Resultaat van een Hyves API aanroep om een lijst van ‘events’ naar ‘eventid’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Voorbeeld van de Hyves4j library . . . . . . . . . . . . . . . . . . Voorbeeld van de Bee.NET library configuration . . . . . . . . . Voorbeeld het gebruik van de Bee.NET library code . . . . . . . Resultaat van een Last.fm API aanroep . . . . . . . . . . . . . . Voorbeeld van de “Last.fm API bindings for Java” library . . . . Voorbeeld van het gebruik van de Last.fm# library code . . . . . Resultaat van een Facebook API aanroep . . . . . . . . . . . . . Voorbeeld van de “facebook-java-api” library . . . . . . . . . . . Voorbeeld van het gebruik van de “Facebook .NET SDK” library code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Resultaat van een Twitter API aanroep . . . . . . . . . . . . . . Voorbeeld van de “Twitter4J” library . . . . . . . . . . . . . . . . Voorbeeld van de “TweetSharp” library . . . . . . . . . . . . . . Resultaat van een LinkedIn API aanroep . . . . . . . . . . . . . .

38

14 15 15 16 17 19 19 21 23 23 26 28 28 31

118

Bijlage G

Literatuuronderzoek Programmeertalen

119

Literatuuronderzoek Programmeertalen

IN3405 - Bachelor Project van Arvind Mohabir - 1324810 Bilal Taouil - 1303570 Koen Boes - 1314785 ntry e-marketing

28 juni 2010 Version 1.0

Opdrachtgevers en begeleiders: Jasper van Blerk Derrick Stomp Peter van Nieuwenhuizen Universiteit Delft Faculty of Electrical Engineering, Mathematics and Computer Science

Samenvatting Een veelgebruikt model voor web services is het Model-View-Controller model. Het helpt de logica apart te houden en zo de koppeling met de andere lagen te vereenvoudigen. De functionele laag (Model) wordt afgezonderd van de grafische interface (View) en de connectielaag (Controller). Programmeertalen die hier gebruik van maken zijn Java EE, ASP.NET en PHP. PHP is een veelgebruikte scripttaal om websites op te zetten. Omdat er een stand-alone applicatie komt, ligt het niet voor de hand om PHP te gebruiken. Java EE en ASP.NET maken allebei gebruik van een objectgeoriënteerde programmeerstijl. De programmeertalen Java en C# zijn wat betreft syntax nagenoeg indentiek. Java EE heeft als voordeel dat door het open karakter de kosten relatief laag zijn en er meer opties zijn, maar betekent tegelijktijd dat men afhankelijker is van de gemeenschap en dat integratie meer werk kost. Aan de andere kant heeft ASP.NET als nadeel dat door het gesloten karakter de kosten hoger liggen en de keuze kleiner kan zijn, maar de integratie kost minder tijd en de applicatie is een consistenter geheel. De libraries van de sociale profielensites zijn beter onderhouden voor ASP.NET dan voor Java. Vanwege de korte duur van het project en de eis voor een eenvoudig te onderhouden softwarelaag is gekozen om ASP.NET met C# te gebruiken.

Inhoudsopgave 1 Inleiding

3

2 Model-View-Controller

5

3 Vergelijking 3.1 Java en Java EE (Sun) . . . . . . . . . . . . . . . . . . . . . . . . 3.2 C# en ASP.NET (Microsoft) . . . . . . . . . . . . . . . . . . . . 3.3 PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7 7 7 8

4 Keuze 4.1 Overweging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Keuze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9 9 10

Bibliografie

11

Lijst van Figuren

12

2

Hoofdstuk 1

Inleiding Voor het bepalen van de programeertaal waarin gewerkt zal worden, moet eerst het type softwareprobleem onderzocht worden. Omdat er gebruik wordt gemaakt van API’s die berichten over het internet versturen, moet er onderzoek worden gedaan naar web services en service-oriented architectures (SOA). Dit staat echter uitgelegd in het literatuuronderzoek over de API’s en wordt hier niet weer uitgelegd. In plaats daarvan zal in dit onderzoek een veelgebruikt softwaremodel voor web services genaamd Model-View-Controller worden uitgelegd. Vervolgens worden drie relevante programmeertalen met elkaar vergeleken om zo de geschikte taal uit te kiezen. De drie talen zijn Java met Java EE, C# met ASP.NET en PHP.

3

4

Hoofdstuk 2

Model-View-Controller Model-View-Controller (MVC) is een softwaremodel om de gebruikersinterfacelaag af te zonderen van de andere delen van het systeem. Het helpt de logica apart te houden en zo de koppeling met de andere lagen te vereenvoudigen. De functionele laag (Model) wordt afgezonderd van de grafische interface (View) en de connectielaag (Controller). [1] Het model is het gedeelte waarin onder andere de instanties van klasses, die databases representeren, kunnen worden opgevraagd en gemanipuleerd. De view bevat objecten die nodig zijn om de data te representeren in een gebruikersinterface. Ook zitten hierin controls die door de gebruiker gemanipuleerd kunnen worden. De controller bevat de klasses die nodig zijn om de interactie tussen de view en het model te sturen. Het softwaremodel heeft als voordeel dat de verschillende componenten onafhankelijk van elkaar ontwikkeld kunnen worden. De communicatie tussen de lagen is tevens laagdrempelig te implementeren en eenvoudig te vinden in de code. Vanwege de scheiding van componenten kunnen verschillende componenten hergebruikt worden. Als laatste kunnen verschillende componenten afzonderlijk van elkaar getest worden. Figuur 2.1: Een eenvoudige weergave van het MVC-model [2]

5

6

Hoofdstuk 3

Vergelijking Vanwege de toename in het gebruik van het internet worden steeds meer alleenstaande applicaties overgezet naar internetapplicaties. De meest gebruikte opties zijn Java EE, ASP.NET en PHP. Java EE is bedacht als oplossing voor internetapplicaties door onder andere Sun, IBM en Oracle. Microsoft heeft met het .NET framework en ASP.NET een robuust pakket gemaakt voor internetapplicaties met eenvoudige intergratie tussen gerelateerde Microsoft-producten. PHP wordt in de vergelijking opgenomen, omdat het een veelgebruikte scripttaal is voor internetapplicaties.

3.1

Java en Java EE (Sun)

Java Platform Enterprise Edition (Java EE) is een standaard, geen fysiek product. [3] Het bestaat uit een aantal afspraken tussen applicaties en containers en werkt volgens het Model-View-Controller softwaremodel. Deze afspraken zijn gemaakt in onderling verband met grote bedrijven als IBM en Oracle en staan in een API. Java is een open programmeertaal en Java EE is een open standaard. Dit kan een voordeel zijn, omdat de gemeenschap meehelpt om een completer product te maken. Tegelijkertijd kan dit ook een nadeel zijn, omdat niet alle mogelijkheden aanwezig hoeven te zijn of even goed hoeven te functioneren. Daarnaast heeft Java de eigenschap, dat het platform-onafhankelijk is. Alle code wordt gecompileerd om vervolgens door de Java Virtual Machine geïnterpreteerd te worden. Dit maakt het eenvoudig om te porten naar andere besturingssystemen, omdat de virtuele machine de code zelf omzet naar machinecode. De virtuele machine zal tevens voor het opruimen van het geheugen zorgen. De kosten van het gebruik van Java en Java EE zijn relatief laag vanwege het open karakter van Java en de hulp van de gemeenschap. Veel software is goedkoop of zelfs gratis. Bovendien zijn door de goedkope software ook de maandelijkse lasten goed te doen voor een klein bedrijf.

3.2

C# en ASP.NET (Microsoft)

ASP.NET is onderdeel van het door Microsoft ontwikkelde .NET framework. [4] Het .NET framework is de opvolger van een ouder platform genaamd Windows DNA. Het .NET framework is geen standaard, maar een productstrategie 7

van Microsoft. ASP.NET is een verzameling van Microsoft-producten, die toegespitst zijn op het gebied van internetapplicaties. Het framework is relatief nieuw en is constant in ontwikkeling. Microsoft moedigt aan om gebruik te maken van diens software. Dit heeft als voordeel dat de applicatie eenvoudig en consistent met de verschillende Microsoftproducten verbonden kan worden, maar zorgt er wel voor dat de programmeur minder vrijheid heeft. Bovendien is het door het gesloten karakter duurder dan een open platform als Java, aangezien het niet gratis is. ASP.NET is de opvolger van ASP, maar is daar niet op gebaseerd. Waar ASP een scripttaal is, kan bij ASP.NET gebruik gemaakt worden van objectgeoriënteerde talen. Alle talen die door het .NET framework geïnterpreteerd kunnen worden, kunnen gebruikt worden. Hieronder vallen onder andere C#, J# (een variant op Java) en Visual Basic. Daarnaast is er door afspraken over standaard exchange sets de mogelijkheid om onderling tussen talen te communiceren. De talen moeten wel ondersteund zijn door het framework. Om dit mogelijk te maken wordt gebruik gemaakt van een interpretator genaamd MSIL. De interpretator kan elke ondersteunde .NET-taal universeel uitvoeren. De code wordt eerst gecompileerd door MSIL en vervolgens bij uitvoer door een Just-In-Time compiler vertaald naar machinecode en uitgevoerd. De MSIL-code is in assembly omgezet. Exact dezelfde code zou door de interpretator bij alle verschillende talen ongeveer even snel moeten zijn. MSIL zorgt ook voor het automatisch opruimen van het geheugen. De code hoeft net zoals bij Java maar een keer gegenereerd te worden en wordt hergebruikt tot de originele code is aangepast. Er zijn methodes om de MSILcode te ontcijferen, maar als het nodig is, kan om beveiligingsredenen de code met behulp van een scrambler ontcijferbaar worden gemaakt. Het .NET framework heeft als troef een ingebouwde API genaamd LINQ [5]. Dit staat voor Language Integrated Query. LINQ maakt gebruik van een query-taal lijkend op SQL om data te verkrijgen van verschillende soorten data. Dit kan op klasses met een speciaal geimplementeerde interface, op relationele databases, op datasets en op XML-bestanden.

3.3

PHP

PHP staat voor Hypertext Preprocessor [6] en is een veelgebruikte scripttaal voor dynamische webpagina’s. Het maakt gebruik van een andere syntax dan Java en C#. Elke pagina wordt opnieuw aangemaakt en geïnterpreteerd door de PHP-engine. Zonder optimalisatie is dit een traag systeem. [7] Ondanks dat PHP een scripttaal is, is er de mogelijkheid om op een objectgeoriënteerde manier te programmeren. Het voordeel van een scripttaal is de relatief lage overheadkosten vanwege de eenvoudigere structuur van het programma. Ook is het eenvoudig om een connectie op te zetten met een relationele database. Het heeft echter niet de mogelijkheid om een op zichzelf staand programma te ontwikkelen. Daarnaast zijn er veel kwetsbaarheden in het systeem te ontdekken. Ongeveer 30 procent van de beveiligingskwetsbaarheden in de Amerikaanse database voor beveiligingskwestbaarheden zijn gerelateerd aan PHP [8] .

8

Hoofdstuk 4

Keuze In dit hoofdstuk zullen de eerder behandelde mogelijkheden met elkaar worden vergeleken. Als eerste worden de overeenkomsten tussen de verschillende talen belicht. Vervolgens zullen de verschillen tussen de talen beschreven worden. Als laatste zal er een keuze gemaakt worden voor de te gebruiken programmeertaal.

4.1

Overweging

Wegens de keuze om een op zichzelf staand programma te ontwikkelen, is PHP afgevallen. Ook moet er een andere taal geleerd worden, wat de keuze minder logisch zou hebben gemaakt. Daarom worden nu ASP.NET met C# en Java EE met Java met elkaar vergeleken. Allereerst worden de overeenkomsten onderzocht. Vervolgens zullen de verschillen naast elkaar worden gezet. Als laatste zal er een keuze uit de twee opties gemaakt worden. De overeenkomsten zijn dat beide talen objectgeorienteerd zijn, geïnterpreteerd worden en dat geheugen automatisch schoongemaakt wordt. Zowel in Java als in C# kan op dezelfde manier geprogrammeerd worden. Ook de syntax is nagenoeg gelijk. Java maakt gebruik van de Java Virtual Machine en het .NET framework maakt gebruik van het soortgelijk functionerende MSIL. Deze interpretators kunnen allebei het geheugen automatisch schoonmaken. De gebruiker hoeft dit niet zelf te doen. Er is geen overeenstemming welke van de twee talen sneller is, maar de talen zullen wat betreft snelheid niet veel van elkaar afliggen, gezien de vrijwel identieke werking. Het grootste verschil is dat bij het .NET framework gekozen is voor een gesloten systeem, waarbij de programmeur afhankelijk is van de leverancier. Dit zorgt voor minder keuze, maar tegelijkertijd voor makkelijkere integratie tussen programma’s onderling en een consistente procedure bij de ontwikkeling van een programma. Daartegenover staat Java EE met een open karakter. De kosten zijn laag of zelfs nihil en er zijn meer opties. Daartegenover is de integratie meer werk dan bij .NET en is men afhankelijk van de software dat door de gemeenschap beschikbaar is gesteld.

9

Omdat het .NET framework samen met ASP.NET een raamwerk is voor de ontwikkeling van web services, is er de mogelijkheid om veel functies als het aanmaken van een web service of het opzetten van de database automatisch te laten doen door de framework. Bij Java EE zal dit zelf moeten worden opgezet. Ontwikkeltools voor Java kunnen dit (deels) op zich nemen. Uit onderzoek naar de API’s is ook gebleken dat de libraries voor C# en ASP.NET beter worden onderhouden dan gelijksoortige libraries voor Java. Dit kan betekenen dat bij eventuele wijzigingen in een API, de makers van de libraries sneller en beter aanpassingen kunnen maken aan hun libraries. Dit heeft als voordeel dat programmeurs sneller op eenvoudige manier aanpassingen kunnen doorvoeren aan hun applicatie. De plan applicatie van ntry is voorlopig in Mono geprogrammeerd, een programmeertaal compatibel met het .NET-framework. De applicatie wordt mogelijk in de toekomst geschreven in Objective-C. De keuze zou niet uit mogen maken, omdat web services onderling met elkaar via een algemeen vastgestelde taal WSDL communiceren.

4.2

Keuze

Vanwege de korte tijd voor het project en de eis voor een makkelijk te onderhouden softwarelaag is gekozen om C# en ASP.NET te kiezen. Het .NET framework heeft al veel standaard tools en libraries voor web services klaar staan voor gebruik. Zo kan vooral op de essentiële delen van de softwarelaag gefocust worden en hoeft men zich niet bezig te houden met randzaken. Daarnaast worden de libraries voor ASP.NET beter onderhouden dan gelijksoortige bij Java.

10

Bibliografie [1] T. C. Lethbridge and R. Laganière, Object-Oriented Software Engineering: Practical Software Development using UML and Java. Mc Graw Hill Education, 2 ed., 2005. Section 9.6: The Model-View-Controller architectural pattern. [2] Sun, “Java SE Application Design With MVC.” http://java.sun.com/ developer/technicalArticles/javase/mvc/, 2007. [3] K. M. et al., Beginning Java EE 5. Apress, 2006. Chapter 1 Java EE Essentials. [4] M. M. et al., Pro ASP.NET 3.5 in VB 2008. Apress, 2008. Chapter 1 Introducing ASP.NET. [5] A. Troelsen, Pro C# 2008 and the .NET 3.5 Platform. Apress, 4 ed., 2007. Chapter 14 An Introduction to LINQ. [6] PHP, “PHP General Information: Manual.” http://nl.php.net/manual/ en/faq.general.php, April 2010. [7] Naspinsky, “Asp.Net vs php : speed comparison.” http://naspinski.net/ post/AspNet-vs-php--speed-comparison.aspx, June 2009. [8] F. Coelho, “PHP-related vulnerabilities on the National Vulnerability Database.” http://www.coelho.net/php_cve.html, 2010. [9] Microsoft, “.NET Micro Framework: About.” http://www.microsoft.com/ netmf/about/default.mspx, 2009.

11

Lijst van figuren 2.1

Een eenvoudige weergave van het MVC-model [2] . . . . . . . . .

12

5

Bijlage H

Handleiding voor de webapplicatie

133

Handleiding Ntry test-webapp

IN3405 - Bachelor Project van Arvind Mohabir - 1324810 Bilal Taouil - 1303570 Koen Boes - 1314785 ntry e-marketing

28 juni 2010 Version 1.0

Opdrachtgevers en begeleiders: Jasper van Blerk Derrick Stomp Peter van Nieuwenhuizen Universiteit Delft Faculty of Electrical Engineering, Mathematics and Computer Science

Inleiding Bedankt voor het gebruik maken van de Ntry test-webapp. In deze handleiding zal de functionaliteit van het programma voor de eindgebruiker uitgelegd worden. Dit zal gedaan worden in combinatie met figuren, die de desbetreffende taak weergeeft. Als eerste zal het inloggen en registreren worden uitgelegd. Daarna zal de functionaliteit in combinatie met sociale profielensites worden uitgelegd. Vervolgens wordt de gebruikersbeheer nader toegelicht. Als laatste wordt uitgelegd hoe het contexten-syteem gebruikt kan worden. Figuur 1: Beginpagina

Inloggen en registreren Om gebruik te kunnen maken van de functionaliteit van de applicatie moet er eerst ingelogd worden. Om in te loggen moet rechtsboven op login worden gedrukt. Op de inlogpagina kunnen de gegevens van de gebruiker worden ingevuld om in te loggen. De gebruiker wordt automatisch doorverwezen naar de hoofdpagina als de login geslaagd is. Registratie kan gedaan worden door naar de inlogpagina te gaan en op het registreer-link te klikken. Vervolgens kan op de registreer-pagina er een account worden aangemaakt door de inloggegevens en gebruikersinformatie in te voeren. De gebruiker wordt bij een geslaagde registratie automatisch ingelogd en doorverwezen naar de hoofdpagina.

Beheer van Sociale Profielensites Om optimaal gebruik te maken van de applicatie zal er toegang tot een of meerdere accounts van sociale profielensites moeten worden verkregen. Op de hoofdpagina verwijst de Bewerk sociale profielensites-knop naar het beheer van 2

Figuur 2: Loginpagina

Figuur 3: Registratiepagina

de sociale profielensites. Op deze pagina kunnen de accounts van de profielensites worden bekeken en verwijderd. Voor het toevoegen van een sociale profielensite wordt een aparte pagina geopend. Op deze pagina moet de sociale profielensite, de link van de profielenpagina en de inloggegevens van de desbetreffende profielensite worden ingevuld. De keuze voor de sociale profielensites bestaat uit drie opties: Hyves, Facebook en Last.FM. De inloggegevens worden eenmalig gebruikt om toegang te verschaffen tot het profiel. Deze inloggegevens worden niet bewaard.

Gebruikersbeheer Wanneer de applicatie toegang heeft tot de informatie op de verschillende sociale profielensites, kan de informatie worden verzameld en worden samengevoegd 3

Figuur 4: Beheerpagina van sociale profielensites

tot een enkel profiel. Voor toegang tot het gebruikersbeheer moet op de Bekijk profiel-knop worden gedrukt. Als de gebruiker bekende informatie bij de applicatie wilt ophalen, kan op de Haal informatie op-knop gedrukt worden. Voor het ophalen van nieuwe informatie van de sociale profielensites, drukt de gebruiker de knop Ververs informatie. De duur van dit proces kan oplopen tot maximaal twee minuten.

Contexten Stel dat de gebruiker niet wil dat andere gebruikers bepaalde evenementen zien. Deze evenementen kunnen nu afgeschermd worden met het contexten-systeem. Evenementen zijn geassocieerd met tags. De gebruiker kan contexten aanmaken en deze contexten vullen met tags. Door middel van de contexten kan de applicatie automatisch bepalen welk deel van jouw informatie andere gebruikers te zien krijgen. Het beheer van de contexten kan gedaan worden middels de context beheerpagina. Om naar deze pagina te gaan, drukt de gebruiker op de Bewerk contexten-knop in het gebruikersbeheer. Op deze pagina kunnen contexten worden aangemaakt, aangepast en verwijderd. In de linkerlijst worden de contexten van de gebruiker weergegeven. In de middelste lijst worden de tags behorend tot de context weergegeven. In de rechterlijst worden alle beschikbare tags weergegeven. Een context kan worden aangemaakt door een naam in te vullen in het tekstveld en op de Voeg context toe-knop te drukken. Om een context te bewerken moet een context gekozen zijn in de linkerlijst. Vervolgens kiest de gebruiker de tags in de rechterlijst en klikt op de Bewerk context-knop. In de gebruikersbeheer-pagina kan een evenement worden geselecteerd. Door op de Bekijk gebruikers van evenement-knop te drukken kan gezien worden welke gebruikers nog meer naar dit evenement gaan en naar welke andere evenementen 4

Figuur 5: Pagina voor het toevoegen van een sociale profielensite

Figuur 6: Gebruikersbeheer-pagina

deze gebruikers gaan.

5

Figuur 7: Contextbeheer-pagina

Figuur 8: Pagina voor bekijken van andere gebruikers

6