Hovedopgave Master i informationsteknologi linjen i softwarekonstruktion

Transkript

1 Hovedopgave Master i informationsteknologi linjen i softwarekonstruktion DLI Admin: Evaluering af performance- og availabilitykvalitet med arkitekturprototyper Michael Kaare Christensen Institut for Datalogi, Aarhus Universitet Åbogade 34, 8200 Århus N Gruppe mac@vfl.dk 9. juni 2013 Abstrakt Dette dokument præsenterer mit arbejde med at opstille krav til og evaluere opfyldelse af arkitekturkvaliteterne performance og availability på systemet DLI Admin, ved hjælp af arkitekturprototyper.

2 Indholdsfortegnelse 1 Motivation Problemformulering Metode og relateret arbejde Om DLI Admin og afviklingsmiljøet Funktionelle områder i DLI Admin Om afviklingsmiljøet Udarbejdelse af Quality Attribute Scenarios Dialog med interessenter Om Quality Attribute Scenarios Terminologi og begreber - availability kvalitetsattributten Terminologi og begreber - performance kvalitetsattributten Performance og availability QAS Webgrænsefladen Performance og availability QAS Service-API Opsummering Arkitekturevaluering med arkitekturprototyper Om arkitekturprototyper og software-arkitektur Karakteriska Klassifikation Prototype-based Architecture Evaluation Arkitekturtaktikker Performance taktikker Availability taktikker Opsummering Webgrænseflade prototype Preconditions definer arkitektur Opsummering Define evaluation goal Implement an evaluation support framework Integrate architectural components Implement architecture model Execute prototype Analyse logs Predict quality attribute Prototype ServiceAPI

3 8.1 Preconditions definer arkitektur Opsummering Define evaluation goal Implement an evaluation support framework Integrate architectural components Implement architecture model Execute prototype Analyse logs Predict quality attribute Konklusion Referencer Bilag 1 Guide til prototyperne Redigering af prototypekildekode Prototypernes struktur Afvikling af prototyperne Bilag 2 DLI Admin udfordringer

4 1 Motivation Videncentret for Landbrug (VFL) har siden 2003 opbygget en brugerdatabase, "brugerdatabasen", indeholdende konti med stamoplysninger på stort set alle landmænd i Danmark. Brugerdatabasen består af en SQL database og et Active Directory, og eksponeres via et antal API er. Den primære anvendelse er som backend for single sign on føderationen [Safewhere] DLBR Fælles Login. Data i brugerdatabasen administreres via et webbaseret administrationssystem kaldet DLI Admin. Gennem de sidste 10 år er DLBR Fælles Login gået fra at være anvendt i en delmængde af VFLs webløsninger, til at være forretningskritisk for stort set alle applikationer på VFL, såvel som for en række af VFLs kunder i landbrugserhvervet via portalen Landmand.dk. Sideløbende har føderations-delen af DLBR Fælles Login gennemgået en transformation, hvor egenudviklet, forældet teknologi og uhensigtsmæssig arkitektur er blevet erstattet med tidssvarende, dokumenterede, standardbaserede produkter, som vedligeholdes af et internt team i VFLs IT-afdeling, VFL IT. I kontrast hertil står DLI Admin og brugerdatabasen. Begge er siden den oprindelige konstruktion blevet videreudviklet af én ekstern konsulent, og er kun i yderst begrænset omfang blevet tilført ressourcer til at holde teknologi, arkitektur og dokumentation ved lige, i forhold til de store mængder ny funktionalitet der er blevet tilført over årene. DLI Admin plages af stabilitetsproblemer og langsomme svartider, hvilket kombineret med den erkendte sårbarhed ved at vedligehold er personafhængig af en ekstern konsulent har resulteret i et ønske om at få insourcet fremtidig videreudvikling til et team internt i organisationen. I forbindelse med denne forankringsproces er der internt i VFL IT en række ønsker og krav, herunder et ønske om at få udarbejdet en fremadrettet arkitektur til DLI Admin, der skal løse de arkitekturelle udfordringer der er med systemet. Fra forretningssiden er der et ønske om at kunne udbyde brugerdatabasens information via en servicesnitflade. 4

5 2 Problemformulering Med udgangspunkt i de ovenfor skitserede problemstillinger vil jeg overordnet introducere DLI Admin systemet, med henblik på at afgrænse den videre analyse til et udsnit af funktionaliteten. Der er en lang række arkitekturrelaterede udfordringer i DLI Admin, men i denne opgave vil jeg afgrænse mig til at behandle udfordringerne relateret til arkitekturkvaliteterne performance og availability. [Christensen et al., 2009] præsenterer en model for aktivitetsområder i softwarearkitekturarbejde, adapteret fra modellen i [Hofmeister et al., 2007]. Modellen skitserer otte aktivitetsområder, hvoraf de tre af områderne danner en kæde, hvor input af krav til systemet (i bredeste forstand) omsættes til et kørende system der kan opfylde disse krav. For hvert af disse tre områder er der et tilsvarende evalueringsområde, hvor det tilhørende områdes output vurderes. Disse tre aktivitetsområder er Arkitekturanalyse, hvor krav til arkitekturen (ikke-funktionelle krav) identificeres, bearbejdes og beskrives Arkitekturdesign, hvor arkitekturen designes og beskrives med udgangspunkt i kravene Arkitekturrealisering, hvor arkitekturen som beskrevet implementeres i et helt eller delvist funktionelt komplet system Ud over de tre plus tre aktivitetsområder der er direkte involveret i kravanalyse, arkitekturdesign og implementation er der to tværgående aktiviteter. Arkitekturstyring dækker over aktiviteter relateret til processen med at skabe arkitekturen. Arkitekturinteraktion handler om formidling af arkitekturen til systemets interessenter. Aktiviteterne itereres efter behov, efterhånden som arkitekturarbejdet afdækker ny viden med relevans for de enkelte områder. Denne opgave vil fokusere på aktivitetsområderne arkitekturanalyse, arkitekturdesign og arkitekturdesignevaluering. Jeg vil gennemløbe disse aktiviteter for udsnittet af DLI Admins funktionalitet, med henblik på at identificere krav til performance og availability, designe en ny arkitektur og evaluere denne i forhold til kravene. Konkret ønsker jeg at anvende Quality Attribute Scenarios (QAS) [Bass et al., 2003] til at identificere og konkretisere krav til den nye arkitektur i DLI Admin, indenfor kvalitetsattributterne performance og availability at anvende arkitekturprototyper [Bardram et al., 2004] for at evaluere de konkretiserede performance- og availability krav i forhold til relevante arkitekturtaktikker 5

6 3 Metode og relateret arbejde Til at udarbejde QAS kunne en mere formaliseret tilgang, såsom en Quality Attribute Workshop [Barbacci et al., 2002], overvejes. Jeg mener dog at være i tilstrækkelig tæt kontakt med systemets interessenter til at kunne identificere de vigtigste krav ved hjælp af uformel dialog, hvorfor jeg har valgt denne tilgang. Arbejdet med arkitekturprototyper vil tage udgangspunkt i klassifikationen og egenskaberne beskrevet i [Bardram et al., 2004]. Til at understøtte udarbejdelsen og evalueringen af prototyperne vil jeg introducere og anvende metoden til arkitekturprototypekonstruktion og arkitekturevaluering beskrevet i [Mårtensson et al., 2003]. For at sikre at der implementeres en arkitektur i prototyperne der kan understøtte de i analysen identificerede mål vil jeg introducere og anvende arkitekturtaktikker, som beskrevet i [Bass et al., 2003]. Jeg har tidligere beskæftiget mig med arkitekturprototyper i [Christensen & Francke-Larsen., 2008], som beskriver arbejdet med at udarbejde og evaluere kandidatarkitekturer baseret på systemet Dyreregistrering, ved hjælp af metoden fra [Mårtensson et al., 2003]. 4 Om DLI Admin og afviklingsmiljøet Som indledning til opgaven vil jeg gennemgå funktionaliteten i DLI Admin, dels for at give en generel introduktion til systemet som resten af opgaven kan relateres til, dels for at identificere et udsnit af funktionaliteten, som jeg arbejder videre med jf. problemformuleringen. Afviklingsmiljøet, forstået som det hardware et system afvikles på, kan have en væsentlig indflydelse på kvaliteterne performance og availability. Jeg runder derfor afsnittet af med en beskrivelse af afviklingsmiljøet for DLI Admin. 4.1 Funktionelle områder i DLI Admin Jeg har dels gennem mit arbejde, dels via dialog med interessenterne på DLI Admin kunnet identificere fire overordnede funktionelle områder der er indeholdt i den eksisterende version Bruger- og organisationsadministration Synkronisering af brugeroplysninger med tredjepart Uddelegering af systemspecifikke rettigheder Abonnementsstyring Disse funktionelle områder trækker på data i den tidligere omtalte brugerdatabase. 6

7 Herudover indeholder DLI Admin er række mindre administrative funktioner, som ikke vil blive behandlet yderligere i denne opgave. Bruger- og organisationsadministrationsdelen (herefter omtalt Webgrænsefladen ) er den primære indgang for administratorer i systemet. Figur 1 - DLI Admin webgrænsefladen, Brugeradministration Her kan man fremsøge brugere ud fra disses registrerede oplysninger, samt redigere alle aspekter af brugerens profil. Der er derudover mulighed for masseudtræk / masseindlæsning via grænsefladen. Synkronisering af brugeroplysninger med tredjepart dækker over muligheden for programmatisk at trække brugeroplysninger ud af DLI Admin, samt muligheden for at opdatere / indlæse selvsamme oplysninger. Dette foregår via det såkaldte Brugerdatabase API (herefter omtalt BDBAPI), en.net komponent, der distribueres til aftagere af data. Komponenten anvendes primært internt på VFL. BDBAPI indeholder funktionalitet til at udtrække og indlæse brugeroplysninger, samt en stor mængde funktionalitet der udgør størstedelen af forretningslogikken under webgrænsefladen. Der er fra IT afdelingens side et ønske om at omlægge denne komponent til et netværksbaseret service-api (herefter omtalt service- API). Uddelegering af systemspecifikke rettigheder dækker over et antal mindre funktionelle områder, hvor der er implementeret uddelegeringssystemer til specifikke systemer. Eksempelvis er der et uddelegeringsmodul til portalen Landmand.dk, og et andet uddelegeringsmodul til benchmarkingsystemet Focus Finder. Jeg vil ikke behandle dette funktionelle område yderligere, da 7

8 min vurdering er at disse uddelegeringssystemer i den fremadrettede arkitektur ikke bør placeres som en del af DLI Admin, men som en del af de specifikke systemer de varetager uddelegering for. Abonnementsstyring dækker over et system, der tildeler og fjerner brugeres adgang til systemer, samt håndterer fakturering af de bagvedliggende abonnementer. Systemet har ingen administrativ snitflade, det administreres direkte ved indtastning af data i de underliggende databasetabeller, som ligger i brugerdatabasen. Dette funktionelle område har jeg fravalgt at behandle yderligere af hensyn til omfanget på opgaven. Således vil resten af denne opgave fokusere på Bruger- og organisationsadministration Service-API (Synkronisering af brugeroplysninger med tredjepart) 8

9 4.2 Om afviklingsmiljøet DLI Admin afvikles i en række forskellige miljøer. Af interesse for denne opgave er primært to miljøer. dev miljøet (udviklingsmiljøet), der er et en samling af servere hvor ny funktionalitet udvikles og testes prod miljøet (produktionsmiljøet), der er en tilsvarende samling af servere der afvikler produktionsudgaven med rigtige brugere i databasen. Jeg har ikke adgang til at afvikle mine prototyper i produktionsmiljøet, hvorfor alle målinger foretages på udviklingsmiljøet. Udviklingsmiljøet er virtualiseret, og afvikles som særskilte virtuelle maskiner modsvarende produktions-konfigurationen, med hensyn til netværk, firewalls, topologi med videre. Hardwaren består af VMWare ESX / VMWare Lab Manager oven på 2 HP480c servere. Disse servere er hver bestykket med 2 x 3.33 GHz Quad-Core CPU er og 48 GB RAM. Udviklingsmiljøet deles mellem over 100 udviklingsservere, hvorfor performance kan være svingende når de øvrige servere er i anvendelse. Jeg har derfor lavet alle målinger i opgaven uden for normal arbejdstid for at sikre så retvisende resultater som muligt. Produktionsmiljøet består af 2 Active Directory servere, hver bestykket med 2 x 2.88 GHz CPU er og 4 GB RAM, 1 SQL Server 2 SQL Server 2008 servere i clusterkonfiguration, hver bestykket med 2 x 3 GHz Quad-Core CPU er og 64 GB RAM 1 Internet Information Server webserver, bestykket med 2 x 2.66 GHz Hexa-Core CPU er og 4 GB RAM I praktisk brug er udviklingsmiljøet væsentligt langsommere end produktionsmiljøet. I særdeleshed når det kommer til disk IO intensive opgaver, såsom databaseforespørgsler. Begge miljøer anvender den samme SAN-platform, men virtualiseringen af denne er øjensynligt forbundet med et stort overhead. Jeg mener derfor at kunne konkludere, at såfremt de senere definerede mål for performance kan opfyldes på udviklingsmiljøet, så vil de også være opfyldt på produktionsmiljøet. 5 Udarbejdelse af Quality Attribute Scenarios Jeg vil behandle de arkitekturelle udfordringer i de to overordnede funktionelle områder særskilt. Afsnittet indledes med en gennemgang min dialog med DLI Admin interessenter om de kvalitetsmæssige udfordringer med systemet. Herefter gives der en generel introduktion til definitioner og klassificeringer inden for området Quality Attribute Scenarios (QAS) og de to kvalitetsattributter availability og performance som opgaven fokuserer på. 9

10 Afsnittet afrundes med at definere QAS for de to funktionelle områder, jf. problemformuleringen. 5.1 Dialog med interessenter Der har op til udarbejdelsen af denne opgave været en periode på omkring et år, hvor jeg har deltaget i dialogen mellem DLI Admins interessenter om produktets fremtid. Parallelt med opgavens udarbejdelse er der blevet igangsat et projekt, hvis mål blandt andet er adressere de identificerede problemstillinger ved produktet, såvel som en række procesmæssige udfordringer, herunder personafhængighed. Man har fra forretningens side, med hjælp fra ITafdelingen, identificeret udfordringerne på et overordnet niveau. Disse udfordringer er opsummeret i et dokument udarbejdet af IT-afdelingen, som jeg har vedlagt som bilag 2. [Bass et al., 2003] bemærker i indledningen til kapitel 4 Systems are frequently redesigned not because they are they are functionally deficient ( ) but because they are difficult to maintain, port, or scale, or are too slow. Dette bekræftes af de identificerede udfordringer i bilag 2, og af min dialog med interessenterne. DLI Admin har funktionalitetsmæssigt fulgt med interessenternes ønsker, men grundet mangel på kvalitetskrav til arkitekturen er der nu en række ikke-funktionelle udfordringer i systemet, som ønskes løst. Hertil kommer de procesmæssige udfordringer. Målet for denne opgave er at identificere udfordringer og krav til selve softwaresystemet DLI Admin, ikke til processen med at udvikle det. Derfor vil jeg ikke behandle de procesrelaterede udfordringer yderligere. Flere af udfordringerne er relateret til arkitekturkvaliteterne availability og performance Brugerne oplever uforklarlige fejl og nedbrud i DLI Admin et availabilityproblem Brugerne oplever at DLI Admin periodisk svarer langsomt et performanceproblem Ønsket om at få strømlinet DLI Admins snitflader mod andre systemer med virksomhedens øvrige netværksbaserede service-api er kan opfattes som et arkitekturkrav til conceptual integrity ([Bass et al., 2003] kapitel 4, afsnit 4.7) på organisationsniveau, men har i kontekst af DLI Admin isoleret mere karakter af et funktionelt krav. Jeg vil dog medtage det som et rammevilkår for udarbejdelse af arkitekturprototyperne. Jeg vil i det efterfølgende afsnit tage udgangspunkt i de to funktionelle områder jeg har valgt ud til videre behandling. For hver af dem vil jeg konkretisere de ovenfor skitserede udfordringer i forhold til området, og identificere de afledte krav til DLI Admins fremadrettede arkitektur inden for performance og availability. Endelig vil jeg formalisere disse krav ved at sætte dem i kontekst og gøre dem målbare i form af et antal QAS. 10

11 5.2 Om Quality Attribute Scenarios Ikke-funktionelle krav, som dem der er opsummeret i bilag 2, skal gøres operationelle før de kan anvendes effektivt i arbejdet med arkitektursyntese. Der er behov for at give dem kontekst og gøre dem målbare, hvis det skal give mening at evaluere hvorvidt den ene arkitekturstilart/-taktik eller den anden bedst kan opfylde kravene. Til dette formål beskriver [Bass et al., 2003] Quality Attribute Scenarios, QAS. QAS introduceres ([Bass et al., 2003] kapitel 4, afsnit 4.3) med udgangspunkt i en overordnet gruppering af kvalitetsattributter. - System Quality Attributes vedrører systemet, hvis arkitektur kvalitetsattributten udtaler sig om. I dette tilfælde altså kvaliteter, der vedrører det fremtidige DLI Admins specifikke arkitektur. - Business Qualities vedrører processen omkring systemets design og konstruktion, samt omkringliggende systemer og organisatoriske rammer. - Architecture Qualities vedrører arkitekturens iboende kvaliteter, der ikke har relation til det konkrete system. For at omsætte et overordnet udsagn om kvalitet til et eller flere QAS er første trin at identificere hvilke kvalitetsattributter inden for de tre kategorier der er relevante for udsagnet. For hver identificeret kvalitetsattribut identificeres - Kilde, hvem sætter scenariet der beskrives i gang? - Stimulus, hvad gør denne kilde? - Artefakt, hvad modtager stimulus? - Miljø, hvilken tilstand er artefaktet i når stimulus optræder? - Respons, hvilken aktivitet bliver taget på baggrund af stimulus? - Responsmål, en måleenhed for responsaktiviteten der kan afgøre om kravet til denne er opfyldt Hver kvalitetsattribut har et generelt scenarie, hvis rolle er at definere et ordforråd som systemspecifikke QAS kan tage udgangspunkt i. Jeg vil i de næste afsnit gennemgå de vigtigste begreber og terminologier inden for performance og availability kvalitetsattributterne. Herefter vil jeg konkretisere udfordringerne i DLI Admin inden for disse kvalitetsattributter, og konkretisere dette til de endelige QAS. 11

12 5.3 Terminologi og begreber - availability kvalitetsattributten Availability drejer sig om system failure and its associated consequences ([Bass et al., 2003] kapitel 4, afsnit 4.4). En failure opstår når systemet holder op med at levere den specificerede service. Man skelner i den forbindelse mellem faults og failure. En fault er først et problem for systemets availability når den bliver en eksternt observerbar failure, hvilket sker såfremt ikke systemet internt håndterer fault en og maskerer den før den propagerer til systemets omgivelser. Givet at en failure kun er en failure såfremt systemet ikke leverer den specificerede service er det muligt at specificere failures væk, fx ved at specificere at et system kan fungere i en forringet tilstand i en periode Faults klassificerer som enten Omission, en komponent svarer ikke på et input Crash, en komponent har gentagne omission faults Timing, komponenten svarer, men svaret kommer for sent eller for tidligt Response, komponenten svarer med en forkert værdi 5.4 Terminologi og begreber - performance kvalitetsattributten [Bass et al., 2003], kapitel 4, afsnit 4.4, beskriver, performance kvalitetsattributten som omhandlende timing, nærmere bestemt beskrives det at ( ) basically performance is concerned with how long it takes the system to respond when an event occurs.. Der er et begrebsmæssigt overlap til timing failures fra availability, der også centrerer sig om timingen i de svar systemet leverer. Dog kan performancekvalitet godt dreje sig om events og tilstande internt i systemet, der ikke nødvendigvis er eksternt observerbare. [Bass et al., 2003] beskriver at det ikke er usædvanligt at der er overlap mellem kvalitetsattributterne, ( ) overlapping attribute concerns ( ), men konkluderer at det ikke er et praktisk problem, da man blot kan eliminere det ene hvis to forskellige kvalitetsattributter frembringer det samme QAS. 5.5 Performance og availability QAS Webgrænsefladen Der er i systemet flere kendte response faults, altså fejl hvor mangelfuld test af systemet betyder at dele af funktionaliteten i DLI Admin leverer et forkert svar på forespørgsler. Det er dog mit klare indtryk fra min dialog med interessenterne, at de udfordringer man oplevere relateret til availability primært falder indenfor omission og crash failures. Der er ikke overblik over de præcise årsager, men der findes driftsstatistik på komponenterne i brugerdatabasen (Active Directory og SQL databasen), 12

13 der indikerer at kilden ikke er disse underliggende datakilder. Derimod trækker DLI Admin på en række andre kildesystemer, som mistænkes for at have periodiske omission og timing failures. Dette giver sat på spidsen ikke mening, givet at der i øjeblikket ikke er defineret formelle krav til hverken performance eller availability i DLI Admin eller kildesystemerne. Men det skal forstås sådan, at systemerne ikke leverer eller for sent leverer svar, i forhold til hvad der med den nuværende DLI Admin arkitektur er nødvendigt for at leve op til de ikke-formaliserede performance og availability forventninger brugerne har. To vigtige funktioner i webgrænsefladen er fremsøgning af brugere, og redigering af disse, hvorfor jeg har udarbejdet nedenstående QAS ud fra disse funktioner. Oprindeligt havde jeg fundet frem til separate availability og performance QAS for scenarie A, men jeg har valgt at kombinere dem jf. diskussionen om overlap ovenfor. Scenarie A : Availability/Performance redigering af bruger, degraded mode Scenarie: En administrator redigerer en bruger mens alle DLI Admins kildesystemer på nær AD og SQL er nede; systemet leverer de tilgængelige data på brugeren inden for maksimalt 3000 ms og udelader data fra de kildesystemer der ikke svarer. Relevant kvalitetsattribut Kilde Stimulus Availability, Performance En administrator af systemet Forespørger redigering af en brugers data Scenariedele Artefakt Miljø Respons DLI Admin Alle kildesystemer som DLI Admin er afhængig af, på nær AD og SQL, svarer ikke Systemet viser et redigeringsbillede med de af brugerens data som er tilgængelige Responsmål Ingen nedetid, det maksimale tidsforbrug for at vise redigeringsbilledet er 3000 ms Scenarie B : Performance redigering af bruger Scenarie: En administrator redigerer en bruger under normal drift; systemet leverer alle data på brugeren inden for maksimalt 1000 ms Relevant kvalitetsattribut Performance Scenariedele Kilde Stimulus Artefakt En administrator af systemet Beder om at redigere en specifik bruger fra en liste af brugere DLI Admin 13

14 Miljø Respons Normal drift Systemet viser et redigeringsbillede med brugerens data Responsmål Det maksimale tidsforbrug for at vise redigeringsbilledet er 1000 ms Scenarie C : Performance søgning efter bruger Scenarie: En administrator søger efter en brugers navn i DLI Admin under normal drift; systemet producerer en liste med de matchende brugere inden for maksimalt 500 ms. Relevant kvalitetsattribut Kilde Stimulus Performance En administrator af systemet Søger efter en brugers navn Scenariedele Artefakt Miljø DLI Admin Normal drift Respons Systemet leverer listen over matchende brugere Responsmål Det maksimale tidsforbrug for at producere listen er 500 ms 5.6 Performance og availability QAS Service- API Det eksisterende BDIAPI er en.net komponent, der indlejres i dataaftagernes egne løsninger. Component & connector (C&C) diagrammet [Christensen et al., 2004] på Figur 1 giver et indblik i brugen af BDBAPI. 14

15 Figur 1 Component & Connector view over DLI Admin, fokus på BDB API På afviklingstidspunktet kommunikerer BDBAPI med Active Directory og SQL Server via protokollerne LDAP og TDS. Det kommunikerer ikke med de øvrige kildesystemer som webgrænsefladen er afhængig af. Jævnfør diskussionen af availability for webgrænsefladen har disse komponenter isoleret set en tilfredsstillende availability, og jeg antager derfor at de ikke i sig selv har en betydende negativ indflydelse på availability for BDBAPI. De kendte udfordringer er performanceproblemer i netværksforbindelserne / firewallprocesseringen fra VFLs DMZ, hvor aftagerne af BDBAPI typisk afvikles, til VFLs backend-netværk, hvor Active Directory og SQL Server afvikles. performanceproblemer relateret til interaktionen mellem BDB API komponenten og hostingplatformen (eksempelvis visse dele af caching-funktionaliteten, der kun fungerer ved web hosting) performanceproblemer relateret til ineffektive algoritmer 15

16 Figur 2 - Allocation view over DLI Admin, fokus på BDBAPI Som det ses på Figur 2, der er et deployment eller allocation diagram [Christensen et al., 2004] over komponenterne fra C&C viewet på Figur 1, så hostes BDBAPI et i en lang række forskelligartede serverprodukter. Disse har hver især har deres egne idiosynkrasier omkring afviklingsmiljøet, som potentielt også kan påvirke BDBAPI ets performance negativt. Som tidligere behandlet er der et ønske om at erstatte det eksisterende brugerdatabase-api med et nyt, netværksbaseret serviceapi. [Fielding, 2000] afsnit sammenligner library-baserede API er med netværksbaserede API er. Om library-baserede API er beskrives A library-based API does a lot more for the programmer, but in doing so creates a great deal more complexity and baggage than is needed by any one system, is less portable in a heterogeneous network, and always results in genericity being preferred over performance. As a side-effect, it also leads to lazy development (blaming the API code for everything) and failure to account for non-cooperative behavior by other parties in the communication. (min fremhævning). Alle de fremhævede passager er udfordringer der er oplevet med det eksisterende BDBAPI, og som søges løst ved skiftet til et netværksbaseret service-api. Givet opgavens fokus vil jeg dog kun opstille mål relateret til kvaliteterne performance- og availability. Med afsæt i ovenstående har jeg konstrueret nedenstående QAS for serviceapi et, inden for kvalitetsattributten performance. 16

17 Scenarie D : Performance forespørgsel på liste af brugere Scenarie: Et system kalder brugerservicen under normal drift, og forespørger en liste af brugere hvis brugernavn indeholder en given streng, brugerservicen producerer listen inden for maksimalt 500 ms. Relevant kvalitetsattribut Kilde Stimulus Performance Et system der aftager brugerservicen Kalder servicen, forespørger liste af brugere hvis brugernavn indeholder en given streng Scenariedele Artefakt Miljø DLI Admin brugerservice Normal drift Respons Systemet leverer listen over matchende brugere Responsmål Det maksimale tidsforbrug for at producere listen er 500 ms Scenarie E : Performance opdatering af brugers data Scenarie: Et system kalder brugerservicen under normal drift, og forespørger opdatering af en eksisterende brugers oplysninger, brugerservicen opdaterer brugerens data og returnerer status inden for maksimalt 500 ms. Relevant kvalitetsattribut Kilde Performance Et system der aftager brugerservicen Scenariedele Stimulus Artefakt Miljø Kalder servicen, forespørger opdatering af en eksisterende brugers oplysninger ud fra brugerens ID DLI Admin brugerservice Normal drift Respons Systemet returnerer status om at opdateringen er gået godt Responsmål Det maksimale tidsforbrug for at opdatere brugerens data og returnere status er 500 ms 17

18 5.7 Opsummering I dette afsnit blev arkitekturanalysen på DLI Admin inden for opgavens afgrænsning gennemført, og der blev identificeret 5 QAS, som kan agere input til arkitektursyntese og efterfølgende evaluering. I næste afsnit introducerer jeg arkitekturprototyper som et værktøj til arkitekturevaluering, og gennemgår en række relevante arkitekturtaktikker jeg vil trække på under arkitektursyntesen. 18

19 6 Arkitekturevaluering med arkitekturprototyper 6.1 Om arkitekturprototyper og softwarearkitektur [Bardram et al., 2004] introducerer arkitekturprototyper som et værktøj til at få hands-on erfaring med en arkitektur inden den konstrueres i sin endelige form. Arkitekturprototyper beskrives som havende en række karakteristika, som adskiller dem fra den traditionelle opfattelse af en softwareprototype Karakteriska Arkitekturprototyper konstrueres for udforskning og læring af/i det arkitekturelle designrum Arkitekturprototyping adresserer udeståender vedrørende arkitekturkvalitetsattributter Hvor softwareprototyper traditionelt anvendes til at afdække samspillet mellem et systems brugere og det funktionalitet, så anvendes arkitekturprototyper som et værktøj til at understøtte de tre aktivitetsområder for softwarearkitektur, analyse, syntese og evaluering. I forhold til anvendelsen på DLI Admin er analyse-delen afdækket tidligere, så prototyperne her vil finde anvendelse som et værktøj til at understøtte arkitektursyntese, og i særdeleshed arkitekturevaluering. Arkitekturprototyper leverer ikke egentlig funktionalitet Fokus i arkitekturprototyper er på at implementere en skeletimplementation af funktionaliteten. Denne skelet-implementation bør repræsentere funktionalitetens forventede interaktion med arkitekturkvalitetsattributterne, men ikke indeholde funktionalitet som sådan. [Bass et al., 2003] nævner kompleks billedbehandling, hvor den forventede interaktion ville være, at processeringsalgoritmen påvirkede systemets performance med en given CPU-belastning. Denne CPUbelastning kunne i en arkitekturprototype genskabes uden at implementere den egentlige billedbehandlingsfunktionalitet. Arkitekturprototyper adresserer typisk arkitekturelle risici Arkitekturelle risici kan både være hvorvidt en given arkitektur opfylder konkrete mål for arkitekturkvalitetsattributter, men også proces-relaterede risici, såsom manglende erfaring med teknologi eller programmeringsmodeller. Fokus i forhold til DLI Admin er på evaluering af opfyldelse af kvalitetsattributscenarierne der tidligere er identificeret. Arkitekturprototyper adresserer problemet med vidensoverførsel og overensstemmelse mellem arkitekturen som-designet og som-bygget. 19

20 Arkitekturprototyperne kan udgøre et praktisk eksempel på implementation af den for arkitekturen relevante arkitekturstilart /de relevante arkitekturtaktikker, som kan hjælpe med overførsel af viden fra arkitekturens designer til dem der skal implementere den. Arkitekturprototypen kan eventuelt bruges som en skeletimplementation, hvorpå funktionaliteten i det endelige system udbygges Klassifikation [Bardram et al., 2004] klassificerer endvidere arkitekturprototyper som værende enten undersøgende ( exploratory ) eller eksperimentelle ( experimental ). Undersøgende arkitekturprototyper anvendes som et kommunikations- og læringsværktøj i forhold til arkitekturen, det system den er designet til og dens interessenter. Eksperimentelle arkitekturprototyper anvendes til at evaluere arkitekturens anvendelig i forhold til dens mål. Jævnfør problemformuleringen vil mit fokus i denne opgave være på at anvende eksperimentelle arkitekturprototyper til at måle på opfyldelsen af de tidligere identificerede QAS. Disse prototyper vil dog starte ud som undersøgende arkitekturprototyper, for at identificere relevante arkitektur taktikker, der kan findes anvendelse til arkitektursyntesen. 6.2 Prototype-based Architecture Evaluation [Mårtensson et al., 2003] beskriver en metode, der konkretiserer processen med at foretage arkitekturevaluering ved hjælp af arkitekturprototyper. Metoden har ikke noget navn, men da den introduceres under overskriften Prototype based architecture evaluation vil jeg efterfølgende omtale den som PBAE-metoden. Metoden er udviklet som en tilpasning af en eksisterende metode til simulations-baseret arkitekturevaluering. De primære tilføjelser til den simulations-baserede evaluering er tilføjelse af trin hvor et evalueringssupportframework konstrueres, samt fokus på at iterere dele af metoden for at sikre at de resultater den producerer er brugbare. Metoden består af en række forudsætninger, samt otte trin. Preconditions Inden evalueringen kan udføres skal en række forudsætninger være opfyldt: Der skal være defineret mindst én arkitektur som prototypen opbygges på baggrund af Hvis der skal evalueres på performance på specifikke delkomponenter i arkitekturen, så skal disse komponenter være tilgængelige Det er en fordel at anvende den afviklingsplatform det endelige system skal køre på til at afvikle prototyperne. [Mårtensson et al., 2003] nævner specifikt hardwareplatformen, men jeg opfatter systemets øvrige omgivelser som værende en del af denne platform. For eksempel eksterne services som systemet kommunikerer med. Dette er årsagen til at jeg, som tidligere 20

21 beskrevet, har valgt at afvikle DLI Admin arkitekturprototyperne i det eksisterende udviklingsmiljø. Define evaluation goal I dette trin definerer man hvad der skal evalueres. Herunder arkitekturkandidater eller komponenter der skal evalueres og hvilke kvalitetsattributter der ønskes målt på. Det fremgår ikke eksplicit at man også her definerer kvantificerbare mål for kvalitetsattributterne, men det antager jeg, ud fra metodens case study, også er en del af dette trin. Centralt for hvad der skal evalueres på er, hvad definerer en DLI Admin arkitekturprototype? Fra listen af karakteristika for arkitekturprototyper ved vi, at de ikke indeholder decideret funktionalitet fra systemet hvis arkitektur prototypen vedrører. Heraf følger spørgsmålet, hvad adskiller den konkrete arkitekturprototype som er modelleret efter et specifikt system fra andre arkitekturprototyper? Specifikt, hvad adskiller prototyper på DLI Admin fra en generisk prototype, givet at det ikke er den funktionalitet systemet indeholder? [Bass et al., 2003] beskriver om forholdet mellem arkitektur og funktionalitet, at software architecture constrains its allocation to structure when other quality attributes are important og the interest of functionality is how it interacts with, and constrains, those other qualities. Heraf mener jeg at kunne udlede, at det der definerer DLI Admin prototyper er hvordan den funktionalitet som DLI Admin indeholder interagerer med og begrænser de ønskede kvaliteter, konkretiseret i de tidligere identificerede QAS. For disse availability og performance-baserede QAS er det væsentligt at identificere funktionalitets- eller omgivelsesfunderede kilder til failure i systemet, samt at identificere relevante performanceflaskehalse. Implement an evaluation support framework Evalueringssupportframeworket tjener to formål, et primært og et sekundært. Det primære formål er opsamling af data med relevans for at evaluere opfyldelse af det tidligere definererede evaluation goal. Sekundært kan evalueringssupportframeworket anvendes til at afkoble de(n) arkitekturkomponent(er) der evalueres på fra arkitekturmodellen. I metodens case study er denne afkoblingen forholdsvist klar. Der evalueres på en kommunikationskomponent, som implementeres særskilt fra den resterende arkitekturmodel og har veldefinerede snitflader mod denne. I forhold til DLI Admin prototyperne vil evalueringssupportframeworket skulle håndtere nogle potentielt mere komplekse snitflader, afhængigt af hvilke arkitekturtaktikker og stilarter der vil finde anvendelse, hvorfor jeg vil fokusere på dataopsamlingsdelen snarere end at forsøge at designe prototyperne til at understøtte en skarp adskillelse mellem arkitekturmodellen, evalueringssupportframeworket og arkitekturkomponenterne. Integrate architectural components I dette trin integrerer man de arkitekturkomponenter der evalueres på med evalueringssupportframeworket. Hvis arkitekturkomponenterne ikke findes i forvejen, eller er blevet udviklet som en del af preconditions-trinnet, må det 21

22 antages at de også udvikles i dette trin, selv om metoden ikke eksplicit definerer dette. Implement architecture model Her samles evalueringssupportframeworket og arkitekturkomponenterne til en eksekverbar arkitekturprototype, der afspejler systemet prototypen bygges på baggrund af. En del af dette trin er også at implementere en runtime opførsel der afspejler de valgte arkitekturstilarter- og metoder hvis komponenter er implementeret i foregående trin. Execute prototype Prototypen afvikles for at opsamle logdata via evalueringssupportframeworket. Det er som tidligere nævnt vigtigt at afviklingsplatformen afspejler den det endelige system forventes afviklet på. Analyse logs De opsamlede logs analyseres med udgangspunkt i de kvalitetsattributter der er valgt ud tidligere. [Mårtensson et al., 2003] påpeger at det ofte vil være en god ide at automatisere denne analyse for at håndtere de potentielt store datamængder der opsamles af evaluereringssupportframeworket. Predict quality attribute Såfremt der ikke er behov for yderligere iterationer afsluttes analysen ved at evaluere arkitekturprototypens opfyldelse af de tidligere definerede mål for kvalitetsattributterne. For DLI Admin vil dette trin være hvor der svares på hvorvidt arkitekturprototyperne kan opfylde det i QAS opstillede responsmål. If necessary, reiterate Såfremt man i forbindelse med et af de foregående trin opnår viden der invaliderer forudsætningerne for at fortsætte analysen itereres et eller flere af de foregående trin. 6.3 Arkitekturtaktikker I arbejdet med at implementere en arkitekturmodel i PBAE-metoden er der behov for at træffe en række designvalg, der påvirker arkitekturen, og dermed prototypens evne til at opfylde de i kvalitetsattributscenarierne opstillede mål. [Bass et al., 2003] kalder sådanne designvalg taktikker, og introducerer for henholdsvis performance og availability et hierarki, hvori en mængde gængse taktikker er beskrevet. Jeg vil gennemgå de to hierarkier, og beskrive de kategorier af taktikker jeg har fundet relevante i arkitekturmodelarbejdet for de to prototyper Performance taktikker [Bass et al., 2003] introducerer målet for performancetaktikker som værende at sikre at et system genererer en passende respons på en hændelse der ankommer til det, inden for en tidsbegrænsning. Latens er den tid et system 22

23 bruger fra en hændelse modtages til responsen er genereret. Latens underopdeles igen i Ressourceforbrug, hvor den begrænsende faktor i processeringshastigheden enten er fysisk, fx CPU, memory, diskeller netværksi-io, eller systeminterne logiske begrænsninger, fx interne processer hvor det er nødvendigt at serialisere afviklingen, hvilket medfører at systemet ikke kan udnytte mere end én CPU af gangen Blokeret tid, hvor der ventes på systemeksterne ressourcer, enten fordi disse ressourcer anvendes af andre systemer og derfor ikke kan svare øjeblikkeligt, fordi disse ressourcer er helt eller delvist utilgængelige, eller fordi det er nødvendigt at synkronisere tilgangen til ressourcerne (eksempelvis at en beregning ressource B udfører for systemet er afhængig af resultatet af en beregning fra ressource A ). Performancetaktikkers formål er således at reducere latens, enten ved at reducere ressourceforbruget eller reducere den blokerede tid, så tidsbegrænsningen kan overholdes. [Bass et al., 2003] klassificerer overordnet performancetaktikkerne som omhandlende ressourceforbrug ( Ressource Demand ), ressourcestyring ( Resource Management ) og ressourcemægling ( Resource Arbitration ). Figur 3 - Performance taktikker (gengivet fra [Bass et al., 2003] figure 5.7) Ressourceforbrug dækker over taktikker i tre underkategorier. Den første underkategori indeholder taktikker der reducerer det ressourceforbrug der er nødvendigt for at behandle indkommende hændelser. Det kan enten ske ved mere effektiv algoritmer ( Increase computation Efficiency ) eller 23

24 reduceret overhead i disse algoritmer ( Reduce computational overhead ), eksempelvis ved at bruge mere effektive frameworks eller reducere/fjerne abstraktionslag. Den anden underkategori indeholder taktikker der reducerer ressourceforbruget ved at reducere mængden af hændelser systemet behandler, enten ved at reducere mængden af hændelser der kommer til systemet ( Manage event rate ), eller ved at udjævne spidsbelastninger på systemet ved at sætte hændelserne i kø til senere behandling ( Control frequency of sampling ). Den sidste underkategori dækker over taktikker, der kontrollerer ressourceforbruget. Ikke som taktikkerne fra første underkategori ved at optimere effektiviteten, men ved at designe algoritmen så den kan afbryde behandlingen når en øvre grænse for hvor lang tid en hændelse kan blive behandlet i er nået ( Bound execution times ). Eller ved at definere en endelig størrelse på antallet af hændelser der kan stå i kø, hvorved spidsbelastninger hvor antallet af hændelser i kø overstiger den maksimale størrelse droppes ( Bound queue sizes ). Kategorien ressourcestyring underopdeles taktikkerne i introduktion af samtidighed ( Introduce concurrency ), vedligehold af multiple kopier af data eller beregninger ( Maintain multiple copies of either data or computations ) og øg tilgængelige ressourcer ( Increase available resources ). Multiple kopier af data som taktik kaldes caching. [Bass et al., 2003] påpeger at man i forbindelse med caching påtager sig opgaven med at sikre at de cachede data er konsistente, dvs. at de matcher de til enhver tid autoritative kildedata, og synkroniserede, altså at eventuelle multiple kopier af cachede data er indbyrdes konsistente. Begge begreber er anvendelsesspecifikke, altså er det en konkret vurdering ved anvendelse af caching hvor hurtigt og baseret på hvilke hændelser konsistens sikres for at opfylde de funktionelle mål for systemet, og i hvilken grad de cachede data er fuldt synkroniserede. Ressourcemægling omhandler hvorledes systemet skal mægle mellem konkurrerende forespørgsler efter de ressourcer det anvender. Det gælder både for de events der ankommer til systemet udefra, men også interne ressourcer administrereret af systemet selv. Jeg har ikke fundet anvendelse for ressourcemæglingstaktikker i mit arbejde med prototyperne Availability taktikker [Bass et al., 2003] introducerer målet for availabilitytaktikker som værende at forhindre faults i at forårsage failures, jf. den tidligere diskussion af disse begreber. Taktikkerne opdeles i tre underkategorier. Fault detection indeholder taktikker, der lader systemet registrere at faults opstår. Enten ved at en komponent overvåger en anden komponent ved kontinuerligt at spørge på dennes status ( Ping/echo ), ved at komponenten der overvåges kontinuerligt sender status ud til en anden komponent ( Heartbeat ), eller ved at komponenten der generer en fault rejser en Exception, der kommunikerer til den kaldende komponent at der er opstået 24

25 en fault, og hvilken klassificering den pågældende fault har ( omission, crash, timing eller response ). Figur 4 - Availability taktikker (gengivet fra [Bass et al, 2003] figure 5.3) Fault recovery / repair indeholder taktikker, der lader systemet reparere faults. Et fælles tema for disse taktikker er, at de komponenter hvor faults skal repareres gøres redundante, fx at de implementeres i forskellig teknologi, afvikles i særskilte processer, eller på separate hardwareplatforme. Voting lader en komponent evaluere output fra en række kopier af den komponent hvis faults potentielt skal reparereres, og udvælger ud fra et situationsspecifikt kriterie, eksempelvis det resultat der produceres flest af, et af resultaterne og videreformidler det. Active Redundancy lader en række kopier af den samme komponent modtage input og beregne output. Alle resultater pånær eet, typisk det første, forkastes. Hermed kan en eller flere instanser af komponenten opleve faults uden at dette kan observeres af modtageren af komponenens output. I modsætning til voting er der ikke en komponent dedikeret til at evaluere om output er korrekt, hvorfor denne taktik ikke beskytter mod response faults. Passive Redundancy lader en primary komponent modtage input og generere output. Ændringer i komponentens tilstand meddeles til en eller flere komponenter, standbys, der opdaterer deres egen tilstand herefter. Ved fejl i primærkomponenten kan en af standby komponenterne overtage primary komponentens rolle, mens denne repareres. Ved Spare forstås en ekstra hardwareplatform, som systemets komponenter kan flyttes over på i tilfælde af failure. Det er nødvendigt at kunne genskabe systemets konfiguration og tilstand på denne nye hardwareplatform. For DLI Admins vedkommende er alle fault recovery / repair taktikkerne anvendt på afviklingsplatformen, eksempelvis: Ved hjælp af Active Redundancy lader Active Directory et antal servere synkronisere med hinanden, og fordeler forespørgsler mellem sig 25

26 SQL Server bruger Passive Redundancy til løbende at synkronisere en passiv server, der kan tage over hvis den primære fejler For Internet Information Server kan der i tilfælde af hardwarefejl hurtigt provisioneres en Spare på VMWare ESX platformen, der kan overtage behandling af nye forespørgsler. Citrix Netscaler laver network load balancing på Internet Information Server, inklusiv regelbaseret Voting på de resultater de enkelte servere producerer, for at sikre at kun svar fra servere der leverer korrekte svar når ud til brugerne. Som tidligere nævnt er der konsensus om at det ikke er afviklingsplatformen for brugerdatabasen der er kilden til availabilityudfordringerne, så jeg vil ikke arbejde videre med udbygning af disse taktikker i denne opgave. De sidste kategorier, fault recovery / reintroduction og fault prevention, har ikke fundet anvendelse i mit arbejde med prototyperne, og jeg vil derfor ikke beskrive dem yderligere. 6.4 Opsummering I dette afsnit introducerede jeg arkitekturprototyper som et værktøj til arkitekturevaluering, herunder en beskrivelse af trinnene i PBAE-metoden som de relaterer sig til DLI Admin prototyperne. Jeg sluttede af med at introducere arkitekturtaktikker, byggesten til arkitektursyntese, og gennemgå en række for DLI Admin prototyperne relevante taktikker indenfor kvalitetesattributterne performance og availability. I de følgende to afsnit vil jeg beskrive mit arbejde med at anvende PBAEmetoden på to prototyper, en baseret på webgrænsefladen og en baseret på service-api et. 26

27 7 Webgrænseflade prototype 7.1 Preconditions definer arkitektur For at opbygge den nødvendige viden til at kunne udarbejde en arkitekturprototype, der retvisende afspejler hvorledes webgrænsefladens funktionalitet interagerer med performance og availability har jeg analyseret på brugsscenarierne Fremsøg bruger og Rediger bruger. Min analyse har taget udgangspunkt i systemets runtime karakteristika baseret på output fra profileren der er indbygget Visual Studio [VS2012Profiler]. Dette har jeg suppleret ved at referere til det eksisterende systems kildekode. Målet er at finde frem til store, negative påvirkninger performance i det eksisterende system, og frasortere de instanser jeg ikke vurderer som værende relevante i en fremadrettet arkitektur. Fremsøg bruger er profilet mens jeg via grænsefladen har søgt på de 20 mest brugte efternavne. Rediger bruger er profilet mens jeg valgte redigering af de 10 øverste resultater for en søgning efter et almindeligt efternavn. Profileren har herudfra genereret et såkaldt call tree, der akkumlerer alle de funktionskald der er foretaget i profilingperioden, med deres tidsforbrug. Call tree et viser og hierarkisk hvilke funktioner der kaldte hvilke funktioner, samt tidsforbruget i funktionen i forhold til det tidsforbrug. Det kan sammenlignes med et UML sekvensdiagram, hvor call tree et dog for det første viser adskillige gennemløb af sekvensen akkumuleret, dels for hvert kald opsamler tidsforbruget i den pågældende funktion på tværs af gennemløb. Der skelnes mellem tidsforbrug i selve funktionen, exclusive samples % og tidsforbrug i funktionen og de underliggende funktioner den kaldte, inclusive samples %. Jeg har via funktionen noise reduction tilpasset call tree et, så det viser alle funktioner der har en inclusive samples % over 2, for lettere at kunne identificere de væsentlige performancepåvirkninger. Herved frafiltreres den funktionalitet i det eksisterende system, som ikke påvirker dets performance væsentligt. Resultatet for Fremsøg bruger kan ses på Figur 5. 27

28 Figur 5 - Filtreret call tree for Fremsøg bruger

29 På øverste niveau ses IIS hostingprocessen, w3wp.exe, der behandler alle requests til ASP.NET via ProcessRequest. Denne funktion kalder videre ned i den egenudviklede kode. Her ses en fordeling mellem fem overordnede funktioner, der alle påvirker performance væsentligt FindBrugere.Searchbutton_Click WebKomponent.OnLoad WebKomponent.PreRender PageInjectionBehavior.DoInjection Findbrugere.BuildControl En nærmere gennemgang af kildekoden afdækker følgende om disse funktioner FindBrugere.Searchbutton_Click bruger tiden på at fremsøge oplysninger om de brugere der matcher fra de valgte kriterier. Læsning af data foregår efter det såkaldte chatty interface antipattern [Meier et al., 2004], hvor der først udføres én forespørgsel mod databasen for at fremsøge en liste af ID er, og derefter udføres lige så mange forespørgsler som i den første liste for at fremsøge oplysninger om disse ID er, en for en. Dette er ikke optimalt fra et performance-synspunkt, givet at en logisk operation resulterer i et antal separate netværksforbindelser til databasen, med tilhørende forespørgsler som databasen må optimere særskilt. Den bagvedliggende egenskab som danner ramme for alle DLI Admin prototyperne er, at de skal fremsøge brugerstamdata fra brugerdatabasens SQL database. WebKomponent.OnLoad bruger tiden på at lave såkaldt databinding, hvor en liste af brugerobjekter renderes som en del af den genererede HTML-side. Det sker ud fra en række ASP.NET specifikke kommandoer, der definerer en mapning mellem objekternes data og HTML. Selve databindingen foretages i FindBrugere.BindGrid(), som man kan notere sig bliver kaldt to forskellige steder fra. Forklaringen er implementationsspecifik, og ikke interessant for prototypen. Den bagvedliggende egenskab er, at de fremsøgte brugerdata skal præsenteres som HTML. WebKomponent.PreRender beder ASP.NET om at udføre databinding på sig selv. Det har ikke været muligt at identificere nogen fornuftig grund til dette muligvis understøtter dette kald andre specialiseringer af WebKomponent, der har behov for at få udført databinding. Denne funktion bidrager således ikke med bagvedliggende egenskaber til DLI Admin prototypen. PageInjectionBehavior.DoInjection er en del af projektets dependency injection container, AutoFac. AutoFac bruger tiden på at instantiere og sammenknytte relaterede instanser som en del af applikationens infrastruktur. Givet at dette ikke er relateret til applikationens funktionalitet, og ikke er en fast defineret del af applikationens fremtidige arkitektur, så er denne funktion heller ikke relevant for DLI Admin prototypen.

30 Findbrugere.BuildControl kaldes af ASP.NET infrastrukturen for at instantiere et objekt ud fra en kombination af deklarativ markup og en traditionel klassedefinition. Ud fra samme argumentation som for AutoFackaldet kan vi også se bort fra denne funktion i DLI Admin prototypen. For Rediger bruger er call tree et væsentligt mere komplekst. 30

31 Figur 6 Filtreret call tree for "Rediger bruger"

32 På øverste niveau under ProcessRequest fordeles tidsforbruget mellem følgende fire funktioner WebKomponent.OnLoad LoadContent.OnInit EditBrugerGenerelt.gemButton_Click PageInjectionBehavior.DoInjection PageInjectionBehavior.DoInjection kan fra start elimineres det er igen kaldet til dependency injection infrastrukturen. WebKomponent.OnLoad har et dybt træ af kald under sig. Ved at gennemgå kildekoden har jeg identificeret følgende som værende af interesse for DLI Admin prototypen: - Der kaldes ned i en Entity Framework databasecontext oven på brugerdatabasen for at hente data om brugerens abonnementer. Entity Framework er et objekt-til-relationel mapningsværktøj, der kan oversætte dataforespørgsler og manipulationer udtrykt i objekter og metoder til SQL udtryk som kan forespørge/manipulere den bagvedliggende database - Der kaldes en webservice, UserRelationService for at hente og gemme data om brugerens sammenknytninger med en række trediepartssystemer. - Der hentes og gemmes stamdata om brugeren via System.DirectoryServices / LDAP i Active Directory - Der hentes og gemmes stamdata på brugeren via ADO.NET i brugerdatabasen - Der hentes hvad der kan betegnes som master data om Landmand.dk portalen via et http-kald, forstået som interne virksomhedsdata der er relativt statiske af natur - Der databindes mellem de fremsøgte data og HTML renderingen af disse At der anvendes flere forskellige teknologier til at tilgå brugerdatabasen mener jeg er en implementationsdetalje, der ikke vedrører prototypen. Brugen af UserRelationService er blevet analyseret af videreudviklingsprojektet på DLI Admin, og det er i den forbindelse blevet besluttet at nedlægge denne service. DLI Admin anvender stadigt oplysninger, men kan trække dem fra sin egen database uden at gå gennem et servicelag Opsummering Opsummeres ovenstående får vi følgende relevante egenskaber for DLI Admin prototypen: - Prototypen skal fremsøge, hente og gemme brugerstamdata i en database der afspejler brugerdatabasens egenskaber, via SQL. Forespørgslerne skal afspejle kompleksiteten fra de rigtige data. - Prototypen skal hente og gemme abonnementsdata i brugerdatabasen via SQL. - Prototypen skal hente og gemme brugerstamdata i Active Directory

33 - Prototypen skal hente brugerrelationsdata fra brugerdatabasens SQL database - Prototypen skal lave et http-kald for at hente data om Landmand.dk portalen. Disse data skal afspejle de rigtige Landmand.dk master data. - Prototypen skal præsentere data via en HTML rendering Alle disse egenskaber er relevante for performance, mens det jævnfør den tidligere diskussion primært er de af dem der vedrører kald til de for DLI Admin eksterne systemer der er relevante for availability. Den ovenstående liste af egenskaber har jeg implementeret i hver deres arkitekturkomponent. Prototypen tager udgangspunkt i en MVC stilart [Microsoft, 2013], implementeret med basis i Microsoft ASP.NET MVC. Jeg har suppleret med en række arkitekturtaktikker, som jeg vil beskrive nærmere i forbindelse med udarbejdelse af arkitekturmodellen. ASP.NET MVC, og dermed MVC arkitekturstilarten, er valgt, da det er den ene af de to webgrænsefladeteknologier der er kompetence i at udvikle og vedligeholde VFL, og fordi jeg, i modsætning til alternativet WebForms, ikke vurderer at dette valg vil påvirke performance negativt. 7.2 Define evaluation goal Målet er at evaluere, hvorvidt en prototype baseret på en MVC stilart suppleret med passende arkitekturtaktikker kan opfylde performance/availabilitymålet defineret i scenarie A - Availability/Performance redigering af bruger, degraded mode, samt hvorvidt det er muligt at opfylde performancemålene defineret i scenarie B - Performance redigering af bruger og C - Performance søgning efter bruger. 7.3 Implement an evaluation support framework Jævnfør de mål der er sat op i scenarie A, B og C, så er det der ultimativt skal måles på tiden fra brugeren initierer den pågældende handling, til browseren er færdig med at rendere resultatet. Af hensyn til at kunne vurdere effekten af de arkitekturtaktikker der er i spil i processen med at producere og levere dette resultat til brugeren er det dog nødvendigt at evalueringssupportframeworket har målepunkter undervejs i processen. Jeg startede med at implementere evalueringssupportframeworket ved hjælp af MiniProfiler [MiniProfiler]. Miniprofiler fungerer dels via instrumentering af nogle af de dataaccess-teknologier der er tilgængelige til.net frameworket, dels ved at man manuelt instrumenterer applikationens kildekode med kald til at starte/stoppe profilingen. Miniprofiler viste sig under det videre arbejde med prototypen som et glimrende værktøj til at skabe indsigt i de SQL-baserede komponenters præcise opførsel og til at måle den totale gennemløbstid for scenarierne. Desværre kan MiniProfiler kun måle på komponenter der eksekverer inden for den samme tråd som MiniProfiler er initialiseret på, hvilket gav problemer ved introduktion af samtidighed i prototypen (beskrives under 33

34 Målt tid i Chrome (ms) Implement Architecture Model ). Jeg har derfor suppleret MiniProfiler med et meget simpelt logframework, der for hver task logger starttidsstempel og id på den eksekverende tråd. Disse data er ikke specielt interessante for en eksperimentel prototype, da kvalitetsattributscenariet alligevel kun opstiller mål for den totale gennemløbstid, men har hjulpet mig med at verificere at teknologien jeg har anvendt til at implementere arkitekturtaktikkerne opfører sig som forventet. Resultatet renderes for mit eget logframework ud som en del af den resulterende HTML-side. Jeg har konfigureret Miniprofiler til både at vise resultaterne som en del af HTMLsiden, men også at logge gennemløbstiden i en SQL database til senere analyse. [Mårtensson et al., 2003] beskriver i metodens case study at det er vigtigt at sikre at evalueringssupportframeworket påvirker prototypens performance mindst muligt, for at kunne opsamle retvisende resultater. Jeg har eksplorativt anvendt netværksperformance-værktøjerne der er indbygget i Googles Chrome-browser. Hermed får jeg målinger, der er uafhængige af mit evalueringssupportframework. Jeg har udført detaljevisning på en fast bruger, og målt på prototypen henholdsvis uden logning, med mit egenudviklede logningsframework, og med både dette framework og miniprofiler slået til. Resultatet kan ses på Figur Detaljevisning for een bruger, gennemløb nummer Ingen logning Egen log Egen log + miniprofiler Figur 7 - Overhead fra evalueringssupportframework Min konklusion på denne måling er, at der ikke er nogen klar tendens der peger på at det ene eller det andet logningsframework har en påvirkning på resultatet som i væsentlig grad vil påvirke opfyldelse af kvalitetsattributscenarierne. 34

35 Figur 8 - MiniProfiler logføring 7.4 Integrate architectural components Jeg har udviklet prototypeudgaverne af arkitekturkomponenterne i dette trin, og integreret dem med MiniProfiler. Komponenterne der henter data fra SQL er udviklet oven på en model af databasen genereret af Microsoft Entity Framework. De fremsøger de samme data som den rigtige DLI Admin gør, fra en brugerdatabase SQL database, der indholdsmæssigt er en kopi fra DLI Admins produktionsmiljø. Komponenten der kommunikerer med Active Directory er bygget med brug af.net frameworkets System.DirectoryServices.AccountManagement klassebibliotek. Den henter data om brugeren fra en kopi af produktionsmiljøets brugerdatabase-active Directory. 35

36 Komponenten der kommunikerer med Landmand.dk anvender Xml deserialisering til at hydrere objekter ud fra den Xml datastruktur der returneres fra Landmand.dk via http. Data hentes fra en kopi af Landmand.dk, der normalt anvendes til udviklingsformål. For alle komponenternes vedkommende har jeg implementeret den mindst mulige funktionalitet der kunne løfte de tidligere identificerede egenskaber, jf. princippet om at arkitekturprototyper ikke indeholder egentlig funktionalitet. 7.5 Implement architecture model Som første gennemløb af dette trin har jeg integreret komponenterne på den simplest mulige måde i et nyt webprojekt, baseret på Microsoft ASP.NET MVC. Komponenterne skabes sammen med den relevante controller af MVC frameworket via en Dependency Injection container. De kaldes synkront af den relevante controller, som illustreret på Figur 9. 36

37 Figur 9 - Sekventielle kald af arkitekturkomponenter

38 Efter at have integreret komponenterne i MVC-modellen var det muligt at afvikle prototypen. Jeg har itereret mellem dette og næste trin, Execute prototype nogle gange. De første data jeg fik ud fra Miniprofiler ved manuelle ad hoc kørsler indikerede flere problemer. Prototypen var ofte ude af stand til at opnå en performance der kunne opfylde scenarie B, og modellen kunne ikke sikre opfyldelse af availabilitydelen i scenarie A, da renderingen fejlede hvis et af kildesystemerne ikke svarede. Jeg konkluderede, at det var nødvendigt at anvende en eller flere performance og availability taktikker. Inden for ressourceforbrug er en mulighed at øge de tilgængelig ressourcer, såsom afviklingsmaskiner med hurtigere CPU(er) eller netværk med lavere latens. Det ville sandsynligvis kunne reducere tidsforbruget på afvikling af de enkelte arkitekturkomponenter. Dog er afviklingsplatformen for webgrænsefladen og de systemer arkitekturkomponenterne kommunikerer med som tidligere beskrevet eksisterende hardware. Der er af omkostningshensyn derfor ikke noget ønske om at anvende denne taktik til at forbedre performance, før der eventuelt måtte være oparbejdet data der indikerer at det ikke er muligt at opfylde de i kvalitetsattributscenarierne opstillede mål på andre måder. Jeg arbejder derfor ikke videre med denne taktik. Webgrænsefladen udfører i sig selv, jf. den tidligere analyse, ikke beregningstung funktionalitet. De systemer som arkitekturkomponenterne kommunikerer med kunne optimeres, men det er uden for scope af denne opgave. Prototypen anvender de nyeste teknologier til henholdsvis webservicetilgang og databaseaccess. Disse teknologier vil generelt have mindre overhead end i de bestående teknologier der har været anvendt i det oprindelige system. Eksempelvis er det tidligere beskrevne chatty interface, hvor der genereres en SQL forespørgsel per fremsøgt bruger elimineret, ved hjælp af Microsoft Entity Framework. Givet at hændelserne for kvalitetsattributscenarierne er brugerhandlinger giver det sig selv at det ikke er muligt at reducere mængden af hændelser (brugerne vil ikke lave færre forespørgsler). At sætte dem i kø er heller ikke relevant, da de hændelser der blev sat i kø så ikke ville levere den i kvalitetsattributscenarierne specificerede performance. Strengt taget kunne det forsvares at droppe hændelser under normal drift, givet at der kun er et availability scenarie defineret for systemet i degraded mode. Men jeg opfatter det som et underforstået krav til arkitekturen at systemet ikke forkaster hele requests for at holde sine svartider. Performance-taktikken Bound execution time, hvor der defineres en øvre grænse for eksekveringstiden på arkitekturkomponenterne kombinerer jeg i prototypen med availability-taktikker, for at løfte det kombinerede performance/availability mål. For at sikre opfyldelse af availability-delen er det nødvendigt at kunne udføre korrekt fault detection på de underliggende arkitekturkomponenter..net frameworket har indbygget support for at begrænse afviklingstiden i form af Task-frameworket i System.Threading.Task. Ved at afvikle hver arkitekturkomponent i en Task,

39 er det understøttet at vente et specificeret tidsrum på at disse eksekverer, og terminere dem på en kontrolleret måde såfremt tiden overskrides. Herved opnås en kombination af taktikkerne Bound execution time og databærende Ping/echo, hvor det at den task der afvikler en given arkitekturkomponent ikke når at svare opfattes som manglende echo. Prototypen er konfigureret til at begrænse eksekveringstiden for komponenterne der tilgår data relations- abonnements- og Landmand.dk data til 2000ms. Værdien er valgt indenfor rammen defineret i kvalitetsattributscenariet for degraded mode, som et kompromis der sikrer at værdien sættes lavt nok til at efterlade et passende tidsrum til processering af de øvrige arkitekturkomponenter og renderingen til HTML og at værdien sættes højt nok til at brugerne vil opleve degraded mode så sjældent som muligt. Fra ressourcestyring virker samtidighed som et oplagt valg til at reducere den totale afviklingstid for arkitekturkomponenterne. [Bass et al., 2003] understreger vigtigheden af at sikre korrekt load balancering mellem de tilgængelige fysiske ressourcer (fx CPU er) ved introduktion af tråde til at opnå samtidighed. Dette er et vigtigt opmærksomhedspunkt i webgrænsefladeprototypen, da komponenterne AbonnementsdataSqlFacade, BrugerdataSqlFacade og RelationFacade henter data fra den samme fysiske databaseinstans. Jeg har implementeret samtidighed med den samme Task-framework som omtalt under ressourceforbrug. Ud over at kunne begrænse eksekveringstiden for et sæt af tasks er det også muligt at starte disse parallelt, hvorefter de afvikles på.net frameworkets thread pool. 39

40 Figur 10 - Parallelle kald af arkitekturkomponenter

41 Caching mener jeg er relevant for de data der leveres af LandmanddkFacade, da disse data som tidligere nævnt har en lav opdateringsfrekvens. En udfordring i anvendelse af caching i forhold til de performance-relaterede kvalitetsattributscenarier er, at man ved caching starter med at forbruge den samme tid eller mere end det ville tage at hente data uden om cachen på at få initialiseret cachen med data. Målet for tidsforbruget er defineret som en maksimumgrænse for vilkårlige hændelser af den pågældende type, inklusiv det første. Derfor skal data indlæses til cachen inden den første hændelse indtræffer, da denne ellers ville ramme en tom cache og eliminere den positive effekt på tidsforbruget af cachingen. Jeg har valgt at initialisere cachen i forbindelse opstart af prototypen, og defineret at cachen har en levetid på 16 timer. Herved tager den første bruger af systemet det ekstra tidsforbrug med at indlæse cachen uden for kvalitetsattributscenariernes hændelser, og cachen er valid godt og vel en efterfølgende arbejdsdag. Cachen er implementeret med.net frameworkets indbyggede cache, HttpRuntime.Cache. 7.6 Execute prototype Udarbejdelsen af prototypen har gennemgået en række undersøgende iterationer med tilhørende eksekvering af prototypen, hvorigennem erfaringerne omkring relevante taktikker og deres praktiske implementation med konkret teknologi, som beskrevet i foregående afsnit, er opsamlet. Efter at have verificeret at den praktiske implementation i prototypen opfører sig som forventet, har jeg sat et struktureret gennemløbsscenarie op. Ligesom ved den oprindelige dataopsamling er mit scenarie, at Fremsøg bruger er udført ved at jeg i grænsefladen har søgt på de 20 mest brugte efternavne. Rediger bruger er udført ved at vælge redigering på de 10 øverste resultater for en søgning efter et almindeligt efternavn. Rediger af bruger, degraded mode er udført ved at konfigurere alle arkitekturkomponenterne på nær dem der kommunikerer med Active Directory og brugerdatabasens SQL database til at blokere i 10 sekunder inden de svarer, og afvikle prototypen som ved Rediger bruger. Udførslen er sket i det tidligere beskrevne udviklingsmiljø. 7.7 Analyse logs MiniProfiler opsamler som tidligere nævnt data i en SQL database. Ved hjælp af en række SQL-forespørgsler har jeg flyttet disse data til Excel, og visualiseret dem på nedenstående tre diagrammer. Alle forespørgslerne har produceret det forventede resultat, og er blevet korrekt håndteret som degraded mode så der er ikke opstået failure under afviklingen.

42 Tidsforbrug (ms) Tidsforbrug (ms) a0fd 7386d c8aa3 f4bdc 503f4 6c6e4 b7792 5ee96 b5bfd 3593a Anonymiserede brugerid'er Figur 11 - Tidsforbrug, redigering af brugere, degraded mode ee073 5e6a9 dd0b8 0569d b3827 ddb3a 8d569 8f0ec 2d2c5 a896b Anonymiserede brugerid'er Figur 12 - Tidsforbrug, redigering af brugere, normal drift 42

43 Jensen Nielsen Hansen Pedersen Andersen Christensen Larsen Sørensen Rasmussen Jørgensen Petersen Madsen Kristensen Olsen Thomsen Christiansen Poulsen Johansen Møller Knudsen Tidsforbrug (ms) Fremsøgt efternavn Figur 13 - Tidsforbrug, fremsøgning af efternavne 7.8 Predict quality attribute Scenarie A : Availability/Performance redigering af bruger, degraded mode relaterer sig til målingerne der er visualiseret på Figur 11. Målet for scenariet er at webgrænsefladen på forespørgsel er i stand til at svare, altså ikke må lade de specificerede underliggende faults fra kildesystemerne udvikle sig til failure. Ydermere er det et krav at svaret produceres indenfor 3000ms. Målingerne på tidsforbrug vist i Figur 11 ligger alle målinger under 3000ms, og alle forespørgsler er blevet behandlet korrekt. Således kan det konkluderes at arkitekturen med anvendelse af de tidligere beskrevne arkitekturtaktikker kan opfylde kvalitetsattributmålet i scenarie A. Scenarie B : Performance redigering af bruger relaterer sig til målingerne der er visualiseret på Figur 12. Målet for scenariet er det samme som for scenarie A, dog uden eksplicitte krav til availability, og i en normal driftstilstand hvor kildesystemerne svarer. Endvidere er tidsgrænsen for hvor hurtigt svaret produceres skal produceres sænket til 1000ms. Som det ses på Figur 12 ligger alle målinger under 1000ms. Således kan det konkluderes at arkitekturen med anvendelse af de tidligere beskrevne arkitekturtaktikker kan opfylde kvalitetsattributmålet i scenarie B. Scenarie C : Performance søgning efter bruger relaterer sig til målingerne der er visualiseret på Figur 13. Målet for scenariet er at webgrænsefladen på forespørgsel er i stand til at fremsøge en liste af brugere der matcher et bestemt navn, på maksimalt 500ms. Som det ses overskider ingen af forespørgslerne der er målt på i prototypen tidsgrænsen, men flere af dem lægger sig meget tæt på. Givet at målingerne er foretaget på udviklingsmiljøet ville det være relevant at gentage målingerne på den rigtige produktionshardware, for at se hvorvidt tidsforbruget er mindre. Det er som tidligere nævnt ikke muligt indenfor scope af denne opgave. Med forbehold for at målingerne er tæt på at overskride grænseværdien må det dog alligevel konkluderes at 43

44 arkitekturen med anvendelse af de tidligere beskrevne arkitekturtaktikker kan opfylde kvalitetsattributmålet i scenarie C. 44

45 8 Prototype ServiceAPI 8.1 Preconditions definer arkitektur Som tidligere diskuteret er det et rammevilkår for prototypen at funktionaliteten til brugersynkronisering fra det eksisterende BrugerdatabaseAPI migreres til et nyt, netværksbaseret serviceapi. I forhold til evaluering af scenarierne er det kun nødvendigt at implementere fremsøgning og opdateringsfunktionaliteten i en skeletudgave. Ved at gennemgå kildekoden har jeg identificeret følgende som værende af interesse for ServiceAPI prototypen: - Der hentes og gemmes stamdata om brugeren via System.DirectoryServices / LDAP i Active Directory - Der hentes og gemmes stamdata på brugeren via ADO.NET i brugerdatabasen. Der anvendes det samme chatty interface antipattern som for webgrænsefladen (se afsnit 7.1) At det eksisterende API behandler data i Active Directory vil jeg vælge at se bort fra i prototypen, da der i videreudviklingsprojektet på DLI Admin arbejdes efter en strategi, hvor brugerens information placeres i SQL databasen. Således er det realistisk at det endelige serviceapi udelukkende behøver behandle information i SQL databasen. Som arkitekturstilart for serviceapi et har jeg valgt at tage afsæt i Representational State Transfer, REST. Afsnit 5.1 i [Fielding, 2000] definerer REST som arkitekturstilart ved at opstille en række constraints. Client server o Serveren udbyder et sæt af services, som klienten kan forespørge Stateless o Al tilstand skal holdes på klienten Cacheable o Data der leveres til klienten skal eksplicit markeres som værende cachebart eller ej Uniform interface o Identification of resources Ressourcerepræsentationer skal kunne adresseres o Manipulation of resources through these representations Ressourcer manipuleres gennem disse repræsentationer. Repræsentationen er ikke ressourcen, men en repræsentation af ressourcen med metadata, der beskriver en given tilstand af denne o Self-descriptive messages De udvekslede beskeder indeholder metadata der beskriver disse, så de kan behandles af systemer mellem client og server (fx en proxy) o Hypermedia as the engine of application state (HATEOAS) 45

46 Aftagere af API et holder ikke viden om dettes strukturering af ressourcer, kun viden om de involverede ressourcetyper (i form af media types). Basalt set skal man kunne navigere sig gennem de ressourcer der udstilles, via hyperlinks der parses ud af ressourcerepræsentationerne Layered system o Det er muligt at introducere systemer mellem client og server (fx en proxy) Code on demand (optionel) o Klienten kan udvides ved at lade ressourcerepræsentationen der udveksles indeholde scriptkode (fx javascript i en html repræsentation) Jeg har valgt at tage udgangspunkt i REST, primært af hensyn til konformitet med VFLs generelle standarder på serviceapi-området, men sekundært på grund af en forventning om på sigt at kunne udnytte flere af RESTs styrker til at optimere eventuelle kvalitetsrelaterede problemer. Eksempelvis vil caching kunne anvendes til at optimere performance for fremsøgning i scenarier hvor den samme forespørgsel udføres gentagne gange. Min prototype vil tage udgangspunkt i Microsofts Web API teknologi. Denne teknologi er udviklet af Microsoft som et alternativ til deres traditionelle SOAP/WS-*-baserede framework, WCF. Hvor WCF blot anvender http som en transportprotokol fordrer Web API anvendelse af http i overensstemmelse med hovedparten af ovenstående principper for REST. ServiceAPI prototypens arkitektur relaterer sig til REST principperne som følger. Principper markeret med fed overholdes af prototypen, mens principper markeret med kursiv er fravalgt. Client server o ServiceAPI et hostes på en server, der udbyder dets ressourcerepræsentationer til klienter Stateless o Serveren er stateless, al information der er påkrævet for at behandle en individuel forespørgsel medsendes i denne fra klienten. Cacheable o ServiceAPI et sætter http s Cache-Control-header i alle svar der sendes til klienten. I prototypen er der ikke implementeret caching, men såfremt data ud fra et forretningsmæssigt synspunkt kan caches i kortere eller længere tid understøttes dette. Uniform interface o Identification of resources Alle ressourcerne (brugere i databasen) kan adresseres med url er o Manipulation of resources through these representations På forespørgsel returneres repræsentationer af brugerne encoded i JSON-format, med et passende 46

47 sæt http-headers der beskriver hvad klienten modtager. Ligeledes modtages ændringer også udtrykt via JSON-repræsentationerne, snarere end den bagvedliggende databasestruktur. o Self-descriptive messages Eksempelvis sendes Content-Type: application/json; charset=utf-8 http headeren. Intermediaries har hermed nok information til at kunne omforme Content-Typen, fx ændre repræsentationen til en XML encoding o Hypermedia as the engine of application state (HATEOAS) På dette punkt fraviger prototypen RESTprincipperne. For at leve op til HATEOAS skal klienten kunne følge hyperlinks fra en serverrod til de for klienten relevante ressourcerepræsentationer. Det kunne fx være et maskinelt forståeligt HTML form lignende hypermedia link fra /brugere/ til top 10 brugere, hvis brugernavn indeholder en specifik tekst, hvor kriterierne blev sat ud fra form input. Dette er ikke implementeret. Prototypen forudsætter i stedet at klienten har implicit viden om ressourcestrukturen ved at basere sig på OData Query Syntax [MS-ODATA, 2011] (afsnit ). Eksempelt ovenfor vil således kunne udtrykkes med en kombination af $top og $filter operatorerne fra OData, men der er ikke et hypermedia link klienten kan følge. Layered system o Som tidligere beskrevet er dette muligt. Eksempelvis har jeg i arbejdet med prototypen anvendt en http proxy, Fiddler, til at inspicere kommunikationen på netværket. Code on demand (optionel) o Denne optionelle constraint er ikke implementeret i prototypen Opsummering Følgende er de relevante egenskaber for DLI Admin serviceapi-prototypen: - Prototypen skal fremsøge, hente og gemme brugerstamdata i en database der afspejler brugerdatabasens egenskaber, via SQL. Forespørgslerne skal afspejle kompleksiteten fra de rigtige data. - Prototypen skal eksponere disse data og operationer som et netværksbaseret serviceapi Det er min forventning at anvendelsen af ovenstående, udvalgte RESTprincipper med Web API vil producere et system, der for de definerede QAS leverer performance på linje med eller bedre end de WCF/SOAP/WS-* baserede serviceapi er jeg tidligere har beskæftiget mig med. 47

48 8.2 Define evaluation goal Målet er at evaluere, hvorvidt en arkitekturprototype baseret på ovenstående liste af udvalgte REST principper, suppleret med passende arkitekturtaktikker, kan opfylde performancemålet defineret i scenarie D: Performance forespørgsel på liste af brugere og E: Performance opdatering af brugers data. 8.3 Implement an evaluation support framework For de to QAS er der er defineret for serviceapi et er den parameter som evaluation support frameworket skal kunne måle på hvor lang tid der går fra klienten forespørger / manipulerer en ressourcerepræsentation til klienten har modtaget et passende svar fra serveren. Til at opsamle denne information har jeg benyttet mig af.net frameworkets Stopwatch-klasse på klientsiden, og udskrevet målingerne i CSV-format til efterbehandling i Excel. For at verificere at resultaterne er retvisende har jeg anvendt Fiddler [Lawrence, 2012] til at undersøge hvorvidt der er forskel mellem tiden som målt, og den tid der reelt anvendes på netværket. Fiddler fungerer ved at skyde sig selv som en http proxy på systemniveau. Ved at etablere separate SSL sessioner med klienten og serveren kan Fiddler overvåge https-baseret kommunikation der passerer gennem den ([Lawrence, 2012] side 98). Fiddler kan på denne måde svare på hvor lang tid serveren er om generere et respons som svar på en forespørgsel fra vilkårlige klienter, renset for eventuelt overhead i klientimplementationen, via Timeline-funktionaliteten ([Lawrence, 2012] side 41). 8.4 Integrate architectural components Jeg startede ud med at implementere klientsiden ved hjælp af Microsofts HttpClient. Jeg kunne dog hurtigt konstatere at der for HttpClients vedkommende var mellem en faktor 2 og en faktor 5 i forskel på den tid som jeg kunne måle med Stopwatch og den tid Fiddler viste at kommunikationen havde taget. Herefter implementerede jeg i stedet klientsiden ved hjælp af.net frameworkets ældre klient til http kommunikation, WebClient. Her kunne jeg ikke konstatere nogen væsentlig forskel i hvad Fiddler afrapporterede og den tid jeg kunne måle med Stopwatch. Konklusionen må være, at der er en væsentlig grad af overhead internt i HttpClient i forbindelse behandlingen af forespørgsel / respons. Med udgangspunkt i Web Apis templates har jeg implementeret serviceapiet som en Controller, BrugereController. Controlleren har to for prototypen relevante indgange public IQueryable<Bruger> GetBrugere(ODataQueryOptions options) og public HttpResponseMessage PutBruger(Guid id, Bruger bruger) 48

49 Førstnævnte mappes af Web Api til http GET operationer uden et specifikt brugerid inkluderet. Ved at eksponere en IQueryable og modtage en ODataQueryOptions eksponeres dem tidligere omtalte OData Query Syntax til klienter, så der kan dannes brugerlister på vilkårlige brugerattributter. Jf. stimulusbegrænsningen i scenarie D anvender jeg kun denne indgang til at forespørge brugerlister på baggrund af brugernavn. Sidstnævnte mappes til http PUT, svarende til opdatering af brugeren. 8.5 Implement architecture model I implementationen af GetBrugere forbindes fremsøgningskriterierne, som Web Api har valideret, med Entity Framework modellen, genbrugt fra Webgrænsefladeprototypen. Hermed kan filtreringen udføres effektivt i den underliggende database. Returværdien er en liste af databasens repræsentation af brugeren omsat til instanser af Bruger-klassen. Disse instanser mappes af Web Api konventionsbaseret til en JSONrepræsentation, der sendes til klienten. Figur 14 - Kald mellem arkitekturkomponenter, GetBrugere I forbindelse med eksekvering og loganalyse kunne jeg konstatere, at arkitekturprototypen som udgangspunkt ikke var i stand til at leve op til kravene defineret i Scenarie D, forespørgsel på liste af brugere. Nærmere analyse af prototypens performance pegede i retning af, at problemet var centreret omkring performance i databasen. Specifikt blev der udført en SUBSTRING operation, som medførte en meget svingende udførselstid. Givet at serviceapiet eksponerer brugerlistefunktionaliteten med OData Query Syntax kunne dette problem spores tilbage gennem Entity Framework og selve serviceapiet til den forespørgsel der var genereret af klienten. Den første implementation af forespørgslen anvendte en OData substringof operator til at fremsøge en brugerliste på baggrund af et bestemt brugernavn. Jeg anvendte arkitekturtaktikken Increase computation Efficiency ved at finde frem til en mere effektiv måde at udtrykke den samme 49

50 bagvedliggende forespørgsel. Ved at bytte substringof ud med indexof kunne tidsforbruget dels reduceres, dels udjævnes i forhold til de udsving jeg havde observeret. Resultater målt med henholdsvis den ene og den anden algoritme er vist i Figur 15 (målt med testen til forespørgsel af brugere, se næste afsnit) Forespørgsel på brugere - tidsforbrug substring/indexof (ms) substring indexof Figur 15 - udførselstid, substring og indexof operatorer Som det ses er substring både langt mindre stabil i sin svartid, og bryder i mange tilfælde 500ms grænsen defineret i scenarie D. PutBruger er implementeret så klienten sender en repræsentation af den modificerede bruger til servicen. Konkret i prototypen er brugeren encoded i JSON-format. Web Api modtager denne repræsentation og fortolker den til en instans af Bruger-klassen. Implementationen af PutBruger validerer at instansen er valid, fx at alle påkrævede felter er udfyldt, og videreformidler den til Entity Framework, der persisterer ændringerne i databasen. 50

51 Figur 16 - Kald mellem arkitekturkomponenter, PutBruger Der var for PutBrugers vedkommende ingen umiddelbare indikationer på at yderligere performancetaktikker var nødvendige for at opfylde scenarie E. 8.6 Execute prototype Til at drive prototypen har jeg anvendt NUnit testframeworket, ved at implementere klienter der kalder de for scenarierne relevante indgange på serviceapiet som tests: TestBulkQueryPerformanceWithinQASLimit (Scenarie D ) TestBulkUpdatePerformanceWithinQASLimit (Scenarie E ) Hver test kalder API'et med 100 forskellige input, svarende til henholdsvis 100 forskellige navne at søge efter, og 100 forskellige brugere at opdatere. Hver test er gentaget 5 gange for at opsamle data på eventuelle periodiske udsving der ikke manifesterer sig under et enkelt gennemløb. Data skrives ud til konsollen i CSV-format, og er importeret i Excel til efterbehandling. 8.7 Analyse logs TestBulkQueryPerformanceWithinQASLimit producerede output som er afbilledet på Figur

52 Tidsforbrug (ms) Tidsforbrug (ms) ServiceAPI - forespørgel på 100 brugere over 5 kørsler med index0f - tidsforbrug per forespørgsel i ms Forespørgsel nummer Kørsel 1 Kørsel 2 Kørsel 3 Kørsel 4 Kørsel 5 Figur 17 - ServiceAPI - forespørgsel på 100 brugere over 5 kørsler TestBulkUpdatePerformanceWithinQASLimit producerede output som er afbilledet på Figur ServiceAPI - opdatering af 100 brugere over 5 kørsler - tidsforbrug per bruger i ms Bruger nummer Kørsel 1 Kørsel 2 Kørsel 3 Kørsel 4 Kørsel 5 Figur 18 - ServiceAPI - opdatering af 100 brugere over 5 kørsler 8.8 Predict quality attribute Scenarie D : Performance forespørgsel på liste af brugere relaterer sig til målingerne der er visualiseret på Figur 17. Målet for scenariet er, at serviceapi er på en forespørgsel efter en liste af brugere hvis brugernavn 52

53 indeholder en given streng kan producere denne liste inden for maksimalt 500 ms. Målingerne på tidsforbrug vist i Figur 17 ligger alle under 500ms på tværs af de 5 kørsler. Der er enkelte udsving der nærmer sig de 500ms, men da der ikke er nogen klar tendens, fx at det er forespørgsler efter det samme brugernavn der konsekvent tager lang tid, finder jeg det mest sandsynligt at de er relateret til load på databaseserveren fra andre systemer. Givet at udsvingene ikke overskrider de 500ms er der ikke konkret behov for at foretage yderligere optimering, især ikke da målingerne er foretaget på det samme virtualiserede miljø som tidligere er beskrevet. Således kan det konkluderes at arkitekturprototypen med anvendelse af de tidligere beskrevne arkitekturtaktikker kan opfylde kvalitetsattributmålet i scenarie D. Scenarie E : Performance opdatering af brugers data relaterer sig til målingerne der er visualiseret på Figur 18. Målet for scenariet er, at serviceapi er på en forespørgsel på opdatering af en eksisterende brugers oplysninger opdaterer brugerens data og returnerer status inden for maksimalt 500 ms. Målingerne på tidsforbrug vist i Figur 18 ligger alle under 500ms på tværs af de 5 kørsler. På samme måde som ved målingerne for scenarie D er der enkelte udsving i svartiden, men for opdateringsscenariet er disse udsving ikke i nærheden af grænsen på 500ms. Således kan det konkluderes at arkitekturprototypen med anvendelse af de tidligere beskrevne arkitekturtaktikker kan opfylde kvalitetsattributmålet i scenarie E. 9 Konklusion I denne opgave ønskede jeg for det første at anvende QAS til at identificere og konkretisere performance- og availabilitykrav til den nye DLI Admin arkitektur. Jeg har gennem dialog med systemet interessenter identificeret de relevante krav der fra forretningsmæssig side er stillet til en ny arkitektur for DLI Admins webgrænseflade og service-api. Disse er blevet fastholdt, konkretiseret, gjort målbare og sat i kontekst ved hjælp af QAS. Dernæst ønskede jeg at anvende arkitekturprototyper til at evaluere arkitekturens opfyldelse af de i QAS fastholdte krav. Jeg har anvendt PBAEmetoden til at udarbejde en arkitekturprototype for henholdsvis webgrænsefladen og service-api et. Disse er baseret på gængse arkitekturstilarter inden for deres respektive områder, og jeg har suppleret med en række arkitekturtaktikker, der understøtter prototypernes opfyldelse af kravene. Som sidste trin i anvendelse af PBAE-metoden har jeg påvist at webgrænseflade- og service-api-prototyperne er i stand til at opfylde kravene. 53

54 10 Referencer [Barbacci et al., 2002] Barbacci, M. R., Ellison, R. J., Lattanze, A., Stafford, J., Weinstock, C. B., & Wood, W. (2002). Quality attribute workshops. Available online: [Bardram et al., 2004] Bardram, J. E., Christensen, H. B., and Hansen, K. M. (2004). Architectural prototyping: An approach for grounding architectural design and learning. In Proceedings of the 4th Working IEEE/IFIP Conference on Software Architecture, pages [Bass et al., 2003] Bass, L., Clements, P., and Kazman, R. (2003). Software Architecture in Practice, 2nd Edition, Addison Wesley, 2003 [Christensen & Francke-Larsen., 2008] Christensen, M. K. and Francke- Larsen, J. W. (2008) DLBR Dyreregistrering i en serviceorienteret arkitektur. Available online: [Christensen et al., 2004] Christensen, H., Corry, A., and Hansen, K. (2004). An approach to software architecture description using UML. Technical report, Computer Science Department, University of Aarhus [Christensen et al., 2009] Christensen, H. B., Hansen, K. M., & Schougaard, K. R. (2009, December). An Empirical Study of Software Architects' Concerns. In Software Engineering Conference, APSEC'09. Asia-Pacific (pp ). IEEE. [Fielding, 2000] Fielding, R. T. (2000) Fielding, R. T. (2000). Architectural styles and the design of network-based software architectures (Doctoral dissertation, University of California) Available online: [Fielding, 2008] Fielding, R. T. (2008) REST APIs must be hypertext-driven. Available online: [Hofmeister et al., 2007] Hofmeister, C., Kruchten, P., Nord, R.L., Obbink, H., Ran, A., America, P. A general model of software architecture design derived from five industrial approaches. The Journal of Systems & Software, 80(1): , [Lawrence, 2012] Lawrence, E. (2012) Debugging with Fiddler: The complete reference from the creator of the Fiddler Web Debugger, CreateSpace Independent Publishing Platform, Tool available at [Meier et al., 2004] Meier, J.D., Vasireddy, Srinath, Babbar, Ashish, Mariani, Rico and Mackman, Alex (2004) Improving.NET Application Performance and Scalability, Microsoft Corporation, 2004 [Microsoft, 2013] Microsoft Corporation (2013) ASP.NET MVC Overview 54

55 Available online: [MiniProfiler] MiniProfiler - A simple but effective mini-profiler for.net and Ruby. [MS-ODATA, 2011] Open Data Protocol (OData) Specification. Available online: [Mårtensson et al., 2003] Mårtensson, F., Grahn, H., and Mattsson, M. (2003) An Approach for Performance Evaluation of Software Architectures using Prototyping. In Proceedings of the IASTED Int'l Conference on Software Engineering and Applications (SEA 2003), pages t [Safewhere] Safewhere Hvad er en føderation? [VS2012Profiler] Analyzing Application Performance by Using Profiling Tools Available online: 55

56 11 Bilag 1 Guide til prototyperne 11.1 Redigering af prototypekildekode Kildekoden til prototyperne findes i det offentligt tilgængelig Git repository på En lokal kopi kan klones ved at installere git, og afvikle følgende kommando fra git bash: git clone git://github.com/michaelkc/dliadminprototypes.git For at kunne kompilere prototyperne er følgende et krav: - Visual Studio 2012 /.NET Framework 4.5 SDK - Adgang til Microsofts NuGet feed for at kunne restore de påkrævede pakker Prototyperne er implementeret i C# Prototypernes struktur Webgrænsefladeprototypen findes i projektet DLIAdmin.Prototypes.Web. Den primære indgang til prototypen er BrugerController, og de(n) tilhørende views / viewmodel i Views/Bruger/ / ViewModels/. Herfra kaldes ud i den øvrige funktionalitet, der overordnet fordeler sig som følger - Models o Autogenereret Entity Framework ORM model der mapper til Brugerdatabasen - Prototype o Egenudviklet kode. Facader mod de systemer DLI Admin er afhængig af, Evaluation Support Frameworket. ServiceAPI-prototypen findes i projektet DLIAdmin.Prototypes.ServiceApi, og ledsages af de i opgaven nævnte tests i projektet DLIAdmin.Prototypes.Tests. Den primære indgang til serviceapi-prototypen er BrugereController. Testprojektet indeholder 5 tests, hvoraf de to af dem er anvendt til at vurdere opfyldelsen af de to performance-qas der er defineret for prototypen: - TestBulkQueryPerformanceWithinQASLimit - TestBulkUpdatePerformanceWithinQASLimit 11.3 Afvikling af prototyperne For at afvikle prototyperne er det nødvendigt at have adgang til VFLs udviklingsmiljø, på grund af afhængighederne til de bagvedliggende 56

57 systemer. Nedenfor har jeg derfor inkluderet en række screenshots, der giver et indblik i hvordan prototypen fungerer. Figur 19 - Webgrænseflade - fremsøgning af bruger Figur 20 - Webgrænseflade - brugerliste 57