Ett onlinebaserat Scania Diagnos
81
Ett onlinebaserat Scania Diagnos JONATAN PETERSSON Examensarbete Stockholm, Sverige 2011
Transcript of Ett onlinebaserat Scania Diagnos
Ett onlinebaserat Scania Diagnos
J O N A T A N P E T E R S S O N
Examensarbete Stockholm, Sverige 2011
Ett onlinebaserat Scania Diagnos
J O N A T A N P E T E R S S O N
Examensarbete i datalogi om 30 högskolepoäng vid Programmet för datateknik Kungliga Tekniska Högskolan år 2011 Handledare på CSC var Alexander Baltatzis Examinator var Stefan Arnborg TRITA-CSC-E 2011:110 ISRN-KTH/CSC/E--11/110--SE ISSN-1653-5715 Kungliga tekniska högskolan Skolan för datavetenskap och kommunikation KTH CSC 100 44 Stockholm URL: www.kth.se/csc
Ett onlinebaserat Scania Diagnos Sammanfattning Scania Diagnos är ett datorbaserat diagnosprogram som utvecklas i en utgåva vid namn SDP3 (Scania Diagnose and Programmer 3). Syftet med programmet är att underlätta och snabba upp verkstadsarbeten så som reparationer, tillsynsarbeten och serviceinsatser som sker mot Scania-utvecklade fordon. Dagens utgåva är ett ”stand alone” program som, efter installation, inte har någon kommunikation med omvärlden avseende uppdateringar med mera. Arbetets syfte har varit att påbörja undersökningen om hur man ska bygga ett framtida Scania Diagnos (arkitektur- och teknikmässigt) som en mer eller mindre tunn klient där kraven på automatisk uppdatering, enkel hämtning och enkel installation uppfylls. Diagnosprogrammet är skrivet i .NET-ramverket och därför inleds rapporten med en teorigenomgång av de tekniker som används för att bygga onlinebaserade lösningar i just det ramverket. De tekniker som har studerats är Silverlight, WPF XBAP, Click-Once, NHibernate, Entity Framework, WCF och WCF RIA Services samt grundläggande klient/server-koncept. I rapporten finns det också motiveringar till varför jag har valt att använda vissa av dessa tekniker istället för andra i arbetet med ett onlinebaserat diagnosprogram. Arbetet var tidsbegränsat och därför belyses, i första hand, hur man, på kort tid, kan åstadkomma en klient/server-arkitektur som uppfyller diagnosprogrammets och Scanias krav och lämnar därmed en tunn klient som en sekundär fokusering. En arkitektur där man placerar dagens lokala Microsoft Access databaser, som utgör 230MB av diagnosprogrammets sammanlagda 340MB, på en extern databasserver med databashanteraren Microsoft SQL Server undersöks. Åtkomst till denna externa server sker sedan med webbtjänster. Dessa exponerar objekt till klientdelen, som använder sig av distribueringstekniken Click-Once för att uppfylla kraven på automatiskt uppdatering, enkel hämtning och enkel installation. Den fysiska arkitekturen som arbetet utmynnat i appliceras på en demilitariserad zon. Tester som jämför dagens diagnosprogram med prototypen av ett onlinebaserat diagnosprogram utförs. Arbetets slutsats är att ett onlinebaserat diagnosprogram är möjligt men att det fortfarande finns frågor som behöver besvaras och studier som behöver utföras.
An online based Scania Diagnose
Abstract Scania Diagnose is a computer based diagnose program which is available and developed in an edition called SDP3 (Scania Diagnose and Programmer 3). The programs purpose is to simplify and speed up repairing and maintenance that needs to be done on vehicles in workshops. The current edition of the program is stand-alone and, after installing it, does not have any communication with the outside world when it comes to updates and so forth. The purpose of this project has been to begin the search for an architectural and technical solution for a future Scania Diagnose as a more or less thin client that fulfils the demands on automatic software updating, easy downloading and easy installation. The diagnose program is developed in the .NET-framework and therefore the report begins with a study of techniques used in general when developing web-based solutions in the framework. The techniques that have been studied are: Silverlight, WPF XBAP, Click-Once, NHibernate, Entity Framework, WCF and WCF RIA Services together with the basics around the client/server-concept. In the report motivations to why I have chosen some of the techniques over others when studying the problem can be found. The work was highly restricted by time and therefore, primarily, only focuses on how to, in the near future, make a client/server-architecture that fulfils the demands of Scania and the diagnose program and thereby leaves the niche of a typical thin client as a secondary focus. The local Microsoft Access databases of today constitutes about 230MB of the diagnose programs total of 340MB. An architecture where you place those databases on an external Microsoft SQL Server has been studied. Access to the external server is then given by web services that exposes objects to the client version of the diagnose program. The remaining diagnose program will then use the distribution technique Click-Once to fulfill the demands on automatic software updating, easy downloading and easy installation. The physical architecture will be a so called demilitarized zone and tests that compare the diagnose program of today with the first prototype of an online based version is made. Based on those tests the conclusion was drawn that an online based program is feasible but that there are still questions to be answered and more studies to be done.
Förord Detta arbete utfördes inom ämnet datalogi vid CSC, KTH Stockholm. Handledare var Alexander Baltatzis. Arbetet är gjort hos och för Scania CV AB i Södertälje där handledaren var Pasi Sivula. Uppgiften till arbetet var ej fördefinierad utan blev definierad, till stor del, av mig tillsammans med min handledare utefter Scanias behov. Jag tackar Gunnar Robertsson (gruppchef för avdelningen YSEI) för möjligheten att göra detta arbete samt för den tid som han har lagt ner till att läsa och kommentera rapporten. Jag tackar även min handledare hos Scania, Pasi Sivula, samt min handledare hos KTH, Alexander Baltatzis, för den tid och det engagemang som dessa har visat för mitt examensarbete. Sist men inte minst vill jag tacka min examensarbetsgrupp för den kontinuerliga genomläsning och kommentering av rapporten som de stått för under arbetets gång.
Innehållsförteckning
1 Inledning .............................................................................................................................1
1.1 Bakgrund ...................................................................................................................................1
1.2 Problem ....................................................................................................................................1
1.3 Syfte ..........................................................................................................................................2
1.4 Begränsningar ...........................................................................................................................2
1.5 Upplägg .....................................................................................................................................3
2 Teori ....................................................................................................................................4
2.1 Allmän teori ..............................................................................................................................4
2.2 Dagens diagnosprogram .......................................................................................................... 10
2.3 Allmän teknologi ..................................................................................................................... 14
2.4 Teknologistack för presentationsnivån (nivå ett) ..................................................................... 19
2.5 Teknologistack för applikationsnivån (nivå två)........................................................................ 21
2.6 Teknologistack för kommunikation mellan klient och server .................................................... 25
3 Metodik och grund till arbetet ..........................................................................................29
3.1 Arbetsmetod och teknikbegränsningar .................................................................................... 29
3.2 Scenariot ................................................................................................................................. 30
3.3 Arkitekturer............................................................................................................................. 31
3.4 Upplägg och prototyp .............................................................................................................. 32
4 Kravinsamling och referenstester .....................................................................................34
4.1 Kravinsamling .......................................................................................................................... 34
4.2 Efterlikna ett riktigt uppkopplingsscenario .............................................................................. 35
4.3 Referenslösning och tester ...................................................................................................... 37
5 Arkitekturer ......................................................................................................................40
5.1 Fysisk arkitektur ...................................................................................................................... 40
5.2 Arkitektur med Entity Framework ........................................................................................... 41
5.3 Arkitektur med nuvarande resurslager .................................................................................... 42
5.4 Diagnosprogrammet med Click-Once ...................................................................................... 42
6 Prototyp och tester ...........................................................................................................43
6.1 Teknik- och arkitekturval för prototypen ................................................................................. 43
6.2 Implementation av prototyp ................................................................................................... 44
6.3 Test av prototyp ...................................................................................................................... 45
7 Analys ...............................................................................................................................48
7.1 Referenslösningen och webbtjänstarkitekturen ....................................................................... 48
7.2 En diagnosprogramsklient ....................................................................................................... 53
7.3 Den fysiska arkitekturen .......................................................................................................... 54
8 Resultat, slutsatser och sammanfattning ..........................................................................56
8.1 Vad har rapporten berört? ...................................................................................................... 56
8.2 Teknikvalen ............................................................................................................................. 56
8.3 Arkitekturen ............................................................................................................................ 57
8.4 Ett onlinebaserat Scania Diagnos möjligt? ............................................................................... 61
9 Framtida rekommendationer ............................................................................................63
9.1 Framtida arbete med arkitekturen .......................................................................................... 63
9.2 Framtida arbete mot en tunn klient ......................................................................................... 63
9.3 Ett annat förslag ...................................................................................................................... 64
Litteraturlista .......................................................................................................................65
Bilagor ..................................................................................................................................67
Ordlista SDP3 Scania Diagnose and Programmer 3. Det är ett verktyg som används av mekanikern
vid fordonsfelsökning.
CAN Controller Area Network. CAN används bland annat för att styra funktioner som
körriktningsvisare, bromsljus och överföra data från tändning, reglage etcetera till bilens centrala dator.
ECU Electronic Control Unit. En styrenhet för styrning av olika system och funktioner. Den
består av hårdvara och programvara.
.NET Ett ramverk utvecklat av Microsoft. Det består av en samling komponenter som
hanterar exekveringen av program som är skrivna speciellt för ramverket.
WPF Windows Presentation Foundation. En av Microsofts ramverkskomponenter för att
rendera och skapa grafiska gränssnitt i .NET-ramverket.
WCF Windows Communication Foundation. En av Microsofts ramverkskomponenter för att
förenkla byggandet av kommunikationsbaserade applikationer.
EF Entity Framework. En av Microsofts ramverkskomponenter för att förenkla
kommunikationen mellan databas och applikation.
SCOMM Scania Communication Module. Komponenten används för att kommunicera med
lastbilens CAN-nätverk och styrenheter.
LINQ Language Integrated Query. Tillhandahåller frågespråksfunktionalitet för .NET-
ramverket.
ADO .NET ActiveX Data Objects. En av Microsofts ramverkskomponenter för att förenkla
kommunikationen mellan databas och applikation.
ORM Object Relational Mapping. Allmänt begrepp för tekniker som beskriver
relationsdatabaser i form av objekt.
VCI Vehicle Communication Interface. Ett gränssnitt för att kommunicera med ett fordon.
WSDL Web Service Definition Language. Ett XML-format för att beskriva webbtjänster och
dess funktioner samt hur dessa anropas.
SSL Secure Sockets Layer. En säkerhetsmekanism som används för att kryptera
kommunikationen mellan två enheter.
MSMQ Microsoft Message Queue. En kö av meddelanden som används i Microsoft
Windows.
XML eXtensible Markup Language. Ett universellt och utbyggbart märkspråk.
XAML eXtensible Application Markup Language. Ett universellt och utbyggbart märkspråk,
baserat på XML.
DMZ DeMilitarized Zone. En fysisk webblösningsarkitektur för att skydda viktig
funktionalitet och information från oönskat intrång.
INLEDNING
1
Kapitel 1
Inledning
1.1 Bakgrund
Den elektroniska utvecklingen har gjort fordon som till exempel lastbilar mer komplexa och därmed krävs mer avancerade felsökningsmetoder. För att kunna felsöka behöver man ett sätt att kunna läsa/skriva information till styrenheterna som finns i fordonen. Därför har Scania utvecklat SDP3 (Scania Diagnose and Programmer 3) som är ett datorbaserat felsökningsverktyg som underlättar och snabbar upp verkstadsarbeten som reparationer, tillsynsarbeten och serviceinsatser. SDP3 kopplar upp sig mot fordonets CAN-nätverk och kan användas för att felsöka, bygga om fordon och ändra egenskaperna för ett fordon. När en mekaniker felsöker, krävs det att han har med sig både sin bärbara dator likväl som kablar för att koppla upp sig mot fordonet. Genom dessa kablar kan SDP3 få ut information från fordonets styrenheter (SDP3 Production Tool – Help, 2010). I dagens lösning finns det enbart möjlighet att installera en full installation av SDP3, på en given dator. Scania vill nu titta på möjligheten att göra detta bredare med en onlinebaserad lösning. Denna lösning kommer att dela upp den nuvarande Scania Diagnos funktionaliteten i två delar, en server och en mer eller mindre tunn klient. Servern ska erbjuda funktionalitet till klienten som åtkomst till databaser, vissa metoder etc. Med detta vill man åstadkomma ett sätt att hålla databaserna och applikationen uppdaterade i alla lägen, vilket inte är fallet idag. Man vill också att kunderna (klienterna) på ett enkelt, smidigt och snabbt sätt ska kunna få tillgång till diagnosprogrammet.
1.2 Problem
Problemformulering baseras på hur man med de krav som finns för dagens diagnosprogram bygger en klient/server-arkitektur. Det finns krav på återanvändning av kod, att kunna presentera realtidsinformation från ett fordon hos klienten, minimerad internettrafik med flera. Andra krav finns på utvecklingsmiljön som måste vara i linje med det Scania använder idag, det vill säga .NET, och kommunikationen mellan servern och klienten måste, så långt det går med dagens tekniker, vara säker, och därmed inte exponera värdefull information för fel personer. Arbetet baseras på frågeställningarna nedan:
Hur ska man dela upp arkitekturen i dagens diagnosprogram för att stödja en klient/server-arkitektur?
Hur tunn kan klienten vara med hänsyn till de krav som ställs på dagens diagnosprogram?
Hur ska man realisera de krav som ställs på ett Scania Diagnos för att på bästa sätt uppfylla dessa?
Vilka tekniker passar för denna typ av problem?
Hur åstadkommer man en säker kommunikation mellan server och klient?
INLEDNING
2
Går det att återanvända den kod som idag finns skriven och därmed skynda på övergångsprocessen till ett onlinebaserat diagnosprogram?
Hur ska man göra för att hålla diagnosprogrammet uppdaterat?
Den onlinebaserade lösningen ska gå att distribuera som en "stand-alone"-lösning, för att felsökningar utan tillgång till Internet ska gå att genomföra.
1.3 Syfte
Detta arbete är avsett att vara en hjälp för Scania när de i framtiden kommer gå över till ett onlinebaserat alternativ av diagnosprogrammet. Syftet är att belysa frågeställningar, påbörja undersökningen samt ge en överblick av området med hänsyn till de krav som ställs på diagnosprogrammets funktionalitet. Utforska vad det är som gör detta diagnosprogram för webben olikt andra övergripande klient/server-lösningar, identifiera problem och om möjligt lösa dessa problem. En av anledningarna till att Scania vill gå över till en onlinebaserad version av diagnosprogrammet är att det ställs krav från EU att man ska kunna köpa det för bara några dagar. Därför vore det absolut smidigast om man, via Internet, kunde gå in och hämta ner programmet relativt snabbt, samtidigt som man vet att det automatiskt kommer att uppdateras i framtiden. Man vill också att databaserna, som är en viktig komponent, ska hållas uppdaterade utan att man behöver uppdatera hela klientdelen av diagnosprogrammet. Målet är att forska fram en identifikation över utstående krav för just detta diagnosprogram och ge rekommendationer om vad man ska tänka på om man väljer att gå över till en onlinebaserad lösning.
1.4 Begränsningar
Detta arbete är begränsat till följande:
De tänkbara tekniker som studeras ligger inom .NET-ramverket. Dessa är Silverlight 4, WPF XBAP, WCF, Click-Once, NHibernate och Entity Framework.
Arbetet belyser, i första hand, enbart separeringen av databaslagret från affärslagret och hur en sådan onlinebaserad arkitektur som uppfyller Scanias krav kan se ut. Detta eftersom det inte finns tid att sätta sig in i hela diagnosprogrammet samt dess kodbas och hur en möjlig tunn klient skulle kunna se ut.
Prototypningen sker på enkla basscenarion, för att undkomma mödan av att behöva sätta sig in hela diagnosprogrammets kodbas. Ett scenario kan till exempel vara möjligheten att från klienten ta emot information från databasen i uppkopplingsögonblicket mot fordonet.
Skalbarheten utanför en server tar arbetet inte fullständig hänsyn till, det vill säga det kommer inte explicit undersökas på hur ett lastbalanseringsalternativ skulle kunna tänkas fungera.
Arbetet inriktar sig i på att ta fram regler, riktlinjer samt rekommendationer för hur eller om ett onlinebaserat Scania Diagnos ska utvecklas i framtiden. Med detta menas att ingen möda kommer att läggas på att implementera de tekniska förslagen i det riktiga diagnosprogrammet.
INLEDNING
3
1.5 Upplägg
Utredningen genomförs i fyra delar. Den första delen är en teoridel som har för avsikt att ge en introduktion till vad en klient/server-arkitektur är samt vilka tekniker som, i sådana arkitekturer, finns att tillgå i .NET. Den andra delen består av en metodbeskrivning, en teknikvalsbeskrivning samt en grundläggande struktur till hur resterande arbete utförs. Del nummer tre är den utförande delen där den arkitektur som jag valt implementeras och jämförs med dagens diagnosprogram. Den sista delen består av analyser och slutsatser kring den arkitektur som arbetet utmynnat i samt hur arbetet mot en tunn klient kan se ut.
TEORI
4
Kapitel 2
Teori Teorikapitlet går igenom den grundläggande informationsmassan som krävs för att förstå senare kapitel där det onlinebaserade diagnosprogrammet studeras. Kapitlet kommer i huvudsak att beröra hur man bygger webblösningar generellt med .NET-ramverket.
2.1 Allmän teori
Detta avsnitt har syftet att gå igenom allmänt kring hur man bygger onlinebaserade applikationer. Avsnittet krävs för att förstå senare teoriavsnitt.
2.1.1 Klient/server-konceptet
Konceptet "klient/server" är ett brett begrepp och innebär generellt att man har en part som tillhandahåller tjänster samt en annan part som konsumerar dessa tjänster. Den tillhandahållande parten brukar betecknas som "servern" och den konsumerade som "klienten". Servern kan tillhandahålla olika tjänster, dessa kan till exempel vara fildelning, skrivardelning, åtkomst till databaser med mera. Klienten och servern hör ihop och därmed går klientens behov av tjänster hand i hand med vad servern konfigureras till att leverera. Allt som oftast ligger klienten och servern på två eller fler skilda datorer, med det är inget krav utan de två parterna skulle kunna ligga på samma dator eller till och med inom samma applikation. Klienten står för både konsumtion och presentation av tjänster likväl som interaktionen med slutanvändaren. Oftast använder klienten sig av mus och tangentbord som interaktionsmedium samt någon form av grafiskt gränssnitt för presentationen (Berson, 1996). Kommunikationen mellan klienten och servern görs med protokoll som på ett eller annat sätt definierar vad som kommuniceras och hur det ska tolkas. Figur 2.1 visar hur en typisk klient/server-arkitektur ser ut, där en serverstack är ett kluster av servrar. Figur 2.1. Två klienter kopplade till en serverstack.
TEORI
5
2.1.2 Fet respektive tunn klient
I en klient/server-arkitektur finns det möjlighet att välja hur mycket av en applikations funktionalitet som ska ligga på servern samt klienten. Väljer man att lägga det mesta av funktionaliteten hos klienten kallas det en fet klient. En sådan klient kännetecknas av att den, i viss mån, kan vara oberoende av en server och i det stora hela klara sig länge utan kontakt med servern (Berson, 1996). En tunn klient är en fet klients motsats vilket innebär att man i en sådan design lägger mycket av funktionaliteten på servern istället. Detta innebär att klienten är helt beroende av servern för att åstadkomma någonting överhuvudtaget. Den absolut tunnaste klienten består enbart av ett gränssnitt och förstår ingenting annat än vad användaren gör mot just detta gränssnitt. Den lämnar alltså över all bearbetning och tolkning av vad användaren gör till servern och förlitar sig på att få ett svar som den kan presentera. Ett typiskt exempel på detta är program som exekveras i en webbläsare som Internet Explorer eller Mozilla Firefox (McKenna, 2002). Sommerville (2007) anser att en stor nackdel med den tunna klienten är att den skapar ett stort tryck på servern i och med att servern måste sköta alla tunga beräkningar åt den. Den utnyttjar inte alls den ofta enorma beräkningskapaciteten som dagens datorer innehar. Denna nackdel går som en fördel hos den feta klienten. En annan nackdel med tunna klienten är att servern blir en akilleshäl vilket betyder att om inte servern fungerar kommer ingenting i systemet fungera. Fördelar med en fet klient:
Använder klientens prestanda. De flesta datorer har hög beräkningskapacitet som är helt gratis att utnyttja.
Möjlighet att köra grafiskt rika applikationer. I den tunna klientens fall skulle detta betyda ett ökat bandbreddsanvändande.
Mindre krav på serverns prestanda samt att flera användare i och med detta kan använda samma server.
Möjlighet att arbeta utan (i en del scenarion) uppkoppling mot Internet. Detta kan i vissa fall vara önskvärt.
Fördelar med en tunn klient:
Har möjlighet att köra väldigt prestandakrävande program på plattformar som inte besitter denna prestanda, till exempel mobiler eller handburna pekskärmar.
Eftersom all kommunikation måste gå igenom den centrala servern kan stora krav på säkerheten uppfyllas.
Enkelt att installera och komma igång med applikationen kombinerat med att dessa moment går snabbt att utföra.
Den tunna klienten är ständigt uppdaterad med den senaste informationen från servrarna. Gäller till stor del även den feta klienten i dagens läge.
TEORI
6
Ovan beskrivs vad man traditionellt avser med en ”tunn” klient respektive ”fet” klient. I en del fall väljer man att hålla sig till dessa beskrivningar, om de passar företaget. Oftast kommer man att välja att använda någonting mittemellan för att få det optimala från båda sidor samt därmed bygga den, utifrån syftet, bästa applikationen.
2.1.3 N-lager och N-nivåer
Ur en klient/server-arkitekturs perspektiv skrivs det oftast om någonting kallat N-nivåer samt N-lager. Skillnaden mellan dessa är om man pratar om den mjuka eller hårda implementationen av arkitekturen. Bokstaven "N" är beteckningen som anger antalet nivåer i arkitekturen. N-lager innebär att man delar upp en applikation i flera logiska lager. De vanligast förekommande är tre stycken lager som delas upp i ett presentationslager, ett processeringslager samt ett databashanteringslager (Lhotka, 2008). Figur 2.2 visar detta.
Figur 2.2. En arkitektur med tre logiska lager (Lhotka, 2008).
Presentationslagret tar hand om all användarinteraktion samt tolkar och distribuerar ner denna till underliggande lager. Affärslagret är kärnan i applikationen och det är där den tyngsta bearbetningen äger rum. Här sköts även kommunikationen med närliggande lager. Datalagret behandlar kommunikationen med databasen och ser till att all data har möjlighet att lagras för att kunna hämtas vid senare tillfälle.
Fördelarna med att dela upp sin applikation i logiska lager är många, några är till exempel:
Man får en logiskt organiserad kod.
Enklare att underhålla.
Smidigare att återanvända.
Högre tydlighet i koden.
TEORI
7
N-nivåer, däremot, innebär att man delar upp en klient/server-arkitektur i flera fysiska delar (nivåer) och låter varje del ta hand om en viss funktionalitet. En nivå får enbart prata med sin närmaste nivå under och sin närmaste nivå ovanför. De vanligaste varianterna man ser av N-nivåer är två-nivåer och tre-nivåer. I en två-nivåers arkitektur delar man upp de två delarna i ett databassystem samt en klient. I en tre-nivåers arkitektur delar man upp de tre delarna i ett databassystem, ett applikationssystem samt ett klientsystem (Lhotka, 2008). Enligt Lhotka (2008) är fördelarna med att använda en uppdelad fysisk arkitektur att man får bättre prestanda, högre skalbarhet, högre feltolerans samt bättre säkerhet. De logiska lagren säger ingenting om hur många fysiska lager det finns. Tumregeln är att det måste finnas minst lika många logiska lager som fysiska lager. Det kan till exempel finnas flera affärslager körandes på samma fysiska maskin (nivå) (Lhotka, 2008). Ett exempel från Sommerville (2007), angående nivåer, är en internetbank. Han menar att en dator hanterar databasärendena, en annan dator hanterar applikationsärendena samt den tredje datorn är klientens maskin körandes en webbläsare. Genom att använda denna uppdelning kan man enkelt lägga till servrar när antalet användare stiger samtidigt som man med enkelhet kan optimera kommunikationen mellan webbservern och databasservern utan att utföra något arbete på klienten alls. Figur 2.3 visar hur en två- samt tre-nivåers arkitektur kan se ut. En jämförelse mellan kostnad och applikationskomplexitet samt livslängd finns också.
Figur 2.3. Bild på en två- och tre-nivåers arkitektur samt en enkel jämförelse (Berson, 1996).
Figur 2.3 beskriver att det för små applikationer finns fördelar att använda sig av ett lägre antal nivåer medan det för en större applikation är bättre med tre eller fler nivåer. Jämförelse mellan två-nivåer och tre-nivåer ur Berson (1996):
Två-nivåer Tre-nivåer
Systemhantering Komplext. (Mer logik hos klienten att ta hand om.)
Mindre komplext. (Applikationen kan bli centralt hanterad på servern.)
TEORI
8
Säkerhet Låg. Hög. (Tjänster eller liknande kan användas.)
Inkapsling av data
Låg. (Datatabeller exponeras.) Hög. (Bara fördefinierade tjänster skickas över nätverket.)
Prestanda Låg. (Många SQL-satser skickas över nätverket samt given data måste laddas ner och analyseras hos klienten.)
Hög. (Bara fördefinierade tjänster skickas över nätverket.)
Skalbarhet Dålig. (Begränsad hantering av klientens kommunikationsmöjligheter.)
Mycket bra. (Koncentrerar inkommande sessioner; kan distribuera trafiken över flera servrar.)
Tillgänglighet Dålig. (Kan inte byta till en annan server vid serverkrasch.)
Mycket bra.
Enkel utveckling Mycket. Sådär. Många ramverk utvecklas för just förenkling av detta.
Att använda sig av en N-lagers arkitektur är att föredra, enligt Lhotka (2008), om applikationen man ska applicera det på är komplex. Detta kan i sig göra att applikationen blir mindre komplex och mer lättöverskådlig. Om applikationen från början inte är komplex kan en applicering av en N-lagers arkitektur leda till att man gör den mer komplex.
2.1.4 Fem logiska lager
Användningen av fem logiska lager är en arkitektur som gör komplexa applikationer mer lättöverskådliga samtidigt som man får en större kontroll över säkerheten (Lhotka, 2008). Dessa fem logiska lager är som följer: Gränssnitt Renderar grafiken samt tar hand om användarinteraktionen. Gränssnittskontroll Agerar som en mellanpart mellan serverns affärslogik och klientens gränssnitt. Tar hand om inmatning från användaren för att skicka det vidare till affärslogiken. Tar också hand om resultatet av affärslogikens bearbetning och visar detta i gränssnittet. Affärslogik Står för all bearbetning som validering, säkerhet med mera.
TEORI
9
Dataåtkomst Agerar mellanhand mellan databaslagret och affärslogiken. Har som uppgift att abstrahera underliggande databastekniker och istället exponera någonting som affärslagret förstår. Med detta menas till exempel att man exponerar objekt som resultat istället för det råa resultatet som en SQL-sats ger. Databas Hanterar den fysiska lagringen och står för uppdatering, skapande, borttagande samt tillgång till en persistent databas eller till ett filsystem. Figur 2.4 visar dessa lager med förslag på vilka tekniker man kan tänkas att använda för respektive lager med .NET-ramverket (de intressanta teknikerna tas upp senare i denna teoridel). Figur 2.4. Fem logiska lager med förslag på respektive tekniker. (Lhotka, 2008).
TEORI
10
2.2 Dagens diagnosprogram
För att få ett grepp om vad dagens diagnosprogram gör och hur det är uppbyggt, har jag ägnat det här avsnittet till att studera det. Detta är viktigt när en analys görs, i senare kapitel, över hur man skulle kunna bygga ett onlinebaserat diagnosprogram.
2.2.1 Beskrivning av dagens diagnosprogram
Dagens diagnosprogram har som syfte att göra interaktionen med lastbilen eller bussen så smidig som möjligt. Fordonen innehåller styrenheter, till exempel kan en motor innehålla en styrenhet som gör det möjligt att ställa in hur motorn ska fungera. Dessa styrenheter arbetar med värden som i sin enkelhet inte går att förstå eller sätta i sitt sammanhang utan gedigna kunskaper om just den specifika styrenheten. Diagnosprogrammet gör de utlästa värdena mer förståeliga genom att kombinera dem med information i form av texter och bilder. Styrenheterna och systemet kring dessa är komplext uppbyggt. En styrenhet innehåller ett antal olika värden och funktioner. Utöver de vanliga värdena finns det olika felkoder som sätts om något inte står rätt till i styrenheten. Diagnosprogrammet tillåter undersökning, kalibrering, omprogrammering och en rad olika funktioner som man kan göra med styrenheterna. En bild på diagnosprogrammet ses i figur 2.5. Figur 2.5. En bild på diagnosprogrammet där man ser de olika arbetstyperna man kan utföra. Det finns även felsökningsmetoder som förenklar undersökningen av lastbilen. Dessa felsökningsmetoder består av ett antal logiska steg och vägar som följs beroende på vad man läser från fordonets styrenheter samt vad felsökaren matar in (SDP3 Arkitektur, 2010). Diagnosprogrammet använder sig av en tjänst vid namn SCOMM (Scania Communication Module) för att kommunicera med lastbilen. Denna kommunikation är möjlig genom att
TEORI
11
koppla ett så kallat VCI (Vehicle Communication Interface) till lastbilen. SCOMM exponerar gränssnitt mot lastbilen; dessa är produkt, styrenheter samt hårdvara. Dessa tre gränssnitt i kombination ger tillgång till hela lastbilen. Det finns även en komponent som på begäran levererar en ny styrenhetsavbild (mjukvara) i de fall man vill byta ut eller uppdatera en styrenhets mjukvara (SDP3 Arkitektur, 2010). SDP3 använder sig av relationsdatabaser för att lagra information som tillhör programmet. Informationen som lagras kan till exempel vara text till felsökningsmetoder. När man startar ett arbete mot ett fordon läser diagnosprogrammet upp informationen som finns i databaserna in i datorns minne. Det finns olika ”arbetstyper” i SDP3, dessa är till exempel:
Kontroll och justering.
Ombyggnad.
Tillsyn. För att kunna använda SDP3 måste man i dagens läge använda sig av en USB-nyckel för autentisering mot programmet. Dessa USB-nycklar kommer i en rad olika varianter där varje variant har olika begränsningar för vad en användare av programmet tillåts göra. Scania håller på att utveckla en mjukvarunyckel för att komma bort från kravet att man måste ha en fysisk nyckel (SDP3 Manual, 2010). Systemet består av många komponenter och varje komponent i sig är komplicerad. Figur 2.6 visar (förenklat) hur detta komplexa system är uppbyggt.
Figur 2.6. Abstraherande bild över dagens diagnosprogram.
TEORI
12
2.2.2 Mjukvarubeskrivning av dagens diagnosprogram
Diagnosprogrammet är skrivet i .NET-ramverket med teknikerna C# och WPF och använder sig av native DLL:er skrivna i C++ som hänger kvar från ”gamla tider”. SDP3 består av affärskomponenter (BC – Business Components). Varje sådan enskild affärskomponent består av tre lager: användar-, affärs- samt resurslager. Användarlagret står för att presentera komponenten till användaren. Affärslagret hanterar all bearbetning och är det lager som står för funktionaliteten samt innehåller affärsobjekten. Resurslagret används för att ge persistens till affärsobjekten. Förutom dessa lager innehåller affärskomponenten en fasad, vilken innehåller gränssnittsklasserna. Detta är det enda externa klienter, som vill använda komponenten, ser. Dessa gränssnittsklasser finns implementerade som tjänster i både användar- och affärslagret (SDP3 Arkitektur, 2010). En bild på en affärskomponent ses i figur 2.7.
Figur 2.7. Bild på en affärskomponent. Resurslagret I nuvarande diagnosprogram använder man Microsoft Access för att åstadkomma persistent lagring med hjälp av databaser. Varje affärskomponent har sin egen databas, det vill säga till exempel ECU, Circuit, Guided Methods med mera. Dessa databaser består av information som varje affärskomponent fylls med. Databaserna har ingen kännedom om varandra, beroenden hanteras helt i affärs- och presentationslagret. Resurslagret erbjuder en generisk typ för persistenta objekt, PLC (Persistent Language Class), och varje affärsobjekt ansvarar för sin möjlighet till persistents genom möjligheten att initiera sig utifrån en PLC-instans. Resurslagret har även ett automatiskt stöd för att hämta upp texter på rätt språk. Här är en lista över dagens krav på databashanteringen (SDP3 Arkitektur, 2010):
Persistera data, ex kretsschema och funktionsdiagram.
Endast en användare.
Transaktionshantering behöver inte tas hänsyn till.
Förhållandevis små datamängder.
Enbart läsningar.
Inga avancerade sökningar mot databasen.
Relationsdatabas.
Access-databas (en .mdb-fil per affärskomponent).
TEORI
13
Dagens resurslager har möjlighet att läsa från en rad olika datakällor, dessa är XML, Access med flera. Detta sker genom ODBC (Open Database Connectivity) som är utvecklat för att abstrahera den underliggande databasen man använder genom att lägga in ett drivrutinslager mellan applikationen och databashanteraren. Figur 2.8 visar en bild över databasernas placering och funktion i hierarkin.
Figur 2.8. Överblickande bild över databaslagrets arkitektur.
Varje databas har samma struktur rent tabellmässigt och gör det därför möjligt att använda samma koncept för att hämta information ur en godtycklig affärsdatabas. Resurslagret erbjuder alltså i sitt gränssnitt en lista av PLC-objekt med förutbestämt datainnehåll och understruktur. Följande förutsättningar finns:
Resurslagret vet hur det skall skapa upp PLC:er, vilken data de skall innehålla samt dess struktur av under-PLC:er.
Verksamhetsobjektet i affärslagret vet hur det skall traversera PLC-strukturen för att hämta upp rätt data.
TEORI
14
2.3 Allmän teknologi
Lite allmänt om de tekniker som den onlinebaserade lösningen kommer att bygga på beskrivs i det här avsnittet. Speciellt viktigt är avsnittet om Click-Once då det onlinebaserade diagnosprogrammet kommer att använda sig av denna distributionsteknik.
2.3.1 Microsoft .NET ramverket
En av grundtankarna när Microsoft utvecklade .NET var att knyta samman olika system med varandra med hjälp av mjukvara. Ramverket .NET utvecklades för att skapa en gemensam plattform som ska hjälpa utvecklare att bygga applikationer likväl som att erbjuda ett sätt att köra dessa. En sådan förenkling är att mycket av den problematik som fanns innan med objektallokeringar samt objektborttagningar på det fria lagringsutrymmet sköts automatiskt. En annan funktionalitet som Microsoft fokuserat på är att applikationer som körs under .NET inte ska vara plattformsberoende utan ska kunna köras på vilken plattform som helst, givet att .NET finns installerat. Det finns många alternativa implementationer av .NET som inte Microsoft äger. En av dessa är Mono som fokuserar på många olika plattformar, bland annat Linux och Mac OS. Ramverket erbjuder också en förenklad installation av applikationer och försöker minimera versionskonflikter (MacDonald, 2010). Det finns två huvudkomponenter inom ramverket, dessa är "Common Language Runtime" och "Base Class Libraries". Common Language Runtime (CLR) Detta är Microsofts implementation av en programmeringsspråksoberoende plattform för utveckling och exekvering av applikationer. Det är i CLR som alla program körs och här sköts grundläggande funktioner såsom minneshantering. Denna minneshantering gör att utvecklaren slipper tänka på minnesläckage eller referenser till objekt då CLR släpper dessa när det inte behövs längre, även kallat lumpsamling (.NET Conceptual Overview, 2010). Base Class Libraries (BCL). Detta är klassbiblioteket som innehåller alla underbibliotek såsom "Windows forms", "ADO .NET" med mera. Genom detta klassbibliotek kan en utvecklare skapa sina applikationer genom att antingen använda redan färdiga klasser, utveckla egna eller kombinera båda två. Detta klassbibliotek är menat att hjälpa samt abstrahera grundläggande funktionalitet för att förenkla utvecklarens arbete (.NET Conceptual Overview, 2010). Program som utvecklas i ramverket kan, på grund av programmeringsspråkoberoendet, skrivas i ett antal olika språk som till exempel C#, Visual Basic, C++ och så vidare.
2.3.2 Microsoft C#
Ett av de programmeringsspråk som utvecklades explicit för .NET-ramverket var Microsoft C#. Grundkriterierna i språket är att det ska vara objektorienterat, kraftfullt samt enkelt. C# är i mångt och mycket baserat på föregångarna C och C++, nackdelen med dessa är att utvecklingen tar lång tid och är mer komplicerad än den behöver vara. Detta löser C# eftersom det är designat till att vara ett språk som det ska gå snabbt att utveckla i samtidigt som det ska vara lätt att lära sig om man tidigare utvecklat i C++ eller C. Man kan enkelt dra paralleller mellan C#/.NET och Java, det som kan göras med hjälp av .NET och tillhörande programmeringsspråk kan också göras med olika Java-tekniker.
TEORI
15
Med tanke på att C# är ett plattformsoberoende språk, i och med .NET-ramverkets oberoende, så kan man dra flera fördelar av detta. Det går till exempel att utveckla grafiska gränssnitt till både Linux och Windows utan att behöva bry sig om hur underliggande arkitekturer eller hjälpfunktioner ser ut i respektive operativsystem. Detta innebär att ett program utvecklat för till exempel Windows sedan går att köra på andra plattformar som Linux eller Mac OS utan att man behöver skriva om det (Troelsen, 2007). Microsoft C# är precis som C++ ett objektorienterat språk som bygger på de objektorienterade principerna för att utveckla program. Det finns många utvecklingsverktyg för Microsoft C# och .NET, ett gratisprogram är Microsoft Visual C# som erbjuder stor funktionalitet. Programmet inkluderar designverktyg, kompilator, projektmallar, redigerare samt en massa annat. Man har även tillgång till .NET- ramverkets alla klassbibliotek som förenklar utvecklingen avsevärt. Detta verktyg är skapat för Microsoft Windows. Möjligheten finns också att utveckla för andra plattformar tack vare Monoprojektet som är gratis att ladda ner och innehåller både en kompilator samt grundläggande delar av .NET- ramverket (Troelsen, 2007). Ett exempel som visar hur “Hello World” skrivs i C#:
using System;
namespace Hello
{
class HelloWorld
{
public static void Main()
{
Console.WriteLine("Hello World!");
}
}
}
2.3.3 Utplaceringsmodellen för Click-Once
Microsoft har utvecklat ett sätt att distribuera applikationer som är skrivna i .NET-ramverket. Distribueringsmodellen går under namnet Click-Once och går ut på att till exempel en utvecklare ska kunna skapa ett program och sedan på ett enkelt sätt göra det tillgängligt för andra. Det enda utvecklaren behöver göra för att, i till exempel Visual Studio, distribuera sin applikation är att publicera den på det stället som önskas och därefter kan den tänkta målgruppen få tillgång till applikationen. Applikationen kommer sedan, varje gång den startas, att uppdateras från källan den installerades ifrån (Noyes, 2007). För att, från klientens perspektiv, få en kvalitetssäkring att inte en applikation distribuerad via Click-Once innehåller virus eller kommer att göra skadliga saker med datorn, baserar sig modellen på ett säkerhetssystem kallat CAS (Code Access Security). Detta säkerhetssystem (i Click-Once:s fall) bygger på att .NET-ramverket, beroende på var Click-Once-applikationen hämtas ifrån, sätter olika begränsningar på hur den applikationen kan interagera med den lokala datorn. Detta görs genom att inspektera hur den ”adress” man installerade applikationen ifrån ser ut. Man kan hämta applikationen från en rad olika ställen till exempel intranätet, internet eller den lokala datorn och beroende på detta får applikationen olika begränsningar (Noyes, 2007).
TEORI
16
När man sedan kör en applikation, som har blivit installerad genom Click-Once, kommer det som applikationen försöker göra att jämföras med vad den är tillåten att göra (beroende på var man installerat den ifrån). Om applikationen försöker göra något som är otillåtet kommer ett felmeddelande generas och handlingen att avbrytas (Noyes, 2007). Det finns möjlighet för klienten att tillåta en applikation distribuerad av Click-Once att göra det den vill göra. Detta görs genom användning av så kallade ”certifikat” som applikationen signeras med. Genom att klienten installerar certifikatet, får applikationen godkännande att göra det den vill (Noyes, 2007). I Visual Studio finns det möjlighet för utvecklaren att bestämma vad applikationen ska begränsas till att göra rent säkerhetsmässigt. Utvecklaren kan också använda sig av fördefinierade säkerhetsbegränsningar och få hjälp med att avgöra vad som krävs för att applikationen ska kunna exekvera utan certifikat. Genom att själv ställa in vad applikationen kräver säkerhetsmässigt kan man komma undan certifikat och istället få en dialogruta vid installationen som indikerar på att ett utökat förtroende krävs (om det man försöker göra inte är tillåtet direkt). Där får användaren själv bestämma om den vill att applikationen ska få det förtroendet eller inte. Dock kommer applikationen inte att få fullt förtroende som vid certifiering utan enbart det förtroende som man själv ställt in (Noyes, 2007). Det finns en annan begränsning i Click-Once (som ej är certifierad) som bestämmer hur mycket data som kan hämtas från källan. Denna är satt till halva diskkvotan vilket normalt brukar vara 125MB (Noyes, 2007). I Internet Explorer måste man också kryssa i ”skript aktivering” för att kunna installera en Click-Once från Internet. En .NET-applikation körs normalt (ej ”Click-Once”) utan några begränsningar hos den lokala datorn, nämligen i ett läge vid namn ”fullt förtroende”. En applikation som körs i fullt förtroende har tillgång till hela datorn och kan göra allt som ett vanligt program kan göra. Kör man sin applikation i Click-Once (hämtad utanför den lokala datorn) tillämpas säkerhetsmodellen ”delvis förtroende” (Trusted Applications, 2010). Delvis förtroende Detta är det förtroende som .NET-ramverket har från början om en applikation hämtas med Click-Once, även kallat att köras säkerhetsmässigt i ”sandlådan”. Här är kommunikationen med den lokala datorn begränsad, till exempel kan man inte alltid komma åt filsystemet eller registret. Det går dock att spara och läsa data på en speciell plats kallad ”isolerad lagring”. Det går även att komma åt externa databaser men enbart genom servern som programmet hämtades ifrån (Trusted Applications, 2010). Begränsningarna som finns för Click-Once rent installationsmässigt är som följer:
Installationen gäller enbart för en användare.
Installationen läggs alltid i en användarspecifik mapp som ej går att påverka.
Det går inte att ändra hur installationsguiden ser ut.
Installationen kan inte lägga till delade komponenter i den globala komponentscachen.
Installationen kan inte utföra fristående operationer så som att skapa databaser.
TEORI
17
Vill man se vad som ingår i det fördefinierade säkerhetslägena, som är till exempel Internet och lokala intranätet, kan man med enkelhet gå in i Visual Studio under projektets egenskaper och välja ”Security”. Här nedan kommer en sammanfattning om vad som tillåts i dessa lägen. Internet
Fildialogsåtkomst.
Isolerad lagringsåtkomst (vilket är en isolerad lagringsarea som Click-Once-applikationen har full tillgång till).
Säkerhetsåtkomst.
Åtkomst till det grafiska gränssnittet.
Skrivaråtkomst.
Media-åtkomst samt åtkomst till webbläsaren. Lokala intranätet
Samma som för ”Internet”.
Reflektionsåtkomst.
DNS-åtkomst.
Miljöåtkomst. Allmänt har man i alla lägen till gång till den ”sida” man hämtade applikationen ifrån. Detta går att avaktivera om man i Visual Studio under projektets egenskaper väljer ”Security” och sedan ”Advanced”. Där finns det en kryssknapp vid namn ”Grant the application access to its site of origin” (Trusted Applications, 2010). Bilder på dels hur publiceringsguiden och dels hur en körning av en Click-Once applikation ser ut finns i figur 2.9 respektive figur 2.10.
TEORI
18
Figur 2.9. Publiceringsguiden för en "Click-Once"-applikation.
Figur 2.10. Bild på hur varningen när man kör en "Click-Once"-applikation ser ut.
TEORI
19
2.4 Teknologistack för presentationsnivån (nivå ett)
Det här avsnittet har som syfte att avgöra vad den onlinebaserade klienten kan tänkas använda sig av för teknik presentationsmässigt som också uppfyller kraven på automatisk uppdatering, enkel hämtning och enkel installation.
2.4.1 WPF / WPF Click-Once
WPF (Windows Presentation Foundation) är ett ramverk för att skriva grafiska gränssnitt i Microsoft Windows. En .NET-applikation som använder sig av gränssnittstekniken WPF går att distribuera med Click-Once. Konceptet, som finns beskrivet innan, går ut på att göra installationen enklast möjlig för användaren genom att man enbart ska behöva trycka på installationsfilen så ska applikationen bli installerad. Beroende på varifrån man hämtar applikationen ifrån (intranätet, Internet, …) så får man olika begränsningar till den lokala datorn (MacDonald, 2010).
2.4.2 WPF Browser Application
En "WPF Browser Application" är ett sätt att köra ett .NET-program i webbläsaren. Det finns begränsningar rent grafiskt som till exempel att man inte kan använda sig av nya fönster eller meddelandeboxar. Dessa begränsningar går att komma undan enbart om man väljer att certifiera sin applikation, det går alltså inte att begära utökat förtroende genom till exempel en dialogruta. Bortsett från detta så följer denna möjlighet ”Click-Once”-säkerhetsmodell och eftersom applikationen körs i webbläsaren följer den också internetzonens begränsningar (MacDonald, 2010).
2.4.3 Silverlight
Silverlight är en del av Microsoft .NET-ramverket för att skapa grafiskt rika och interaktiva applikationer för webben. Silverlight är både plattformsoberoende och webbläsaroberoende i och med att Silverlight är ett plugin. Begränsningen sitter i att webbläsaren och operativsystemet måste stödja detta plugin. Silverlight finns också för Linux men då kallat Moonlight (ej utvecklat av Microsoft). Stöd för video och ljud finns och applikationer som utnyttjar detta kan användas. Grafik och animationer kan också användas med Microsoft Silverlight. Silverlight kan, förenklat, ses som en delmängd av gränssnittspråket WPF och är därmed inte lika kraftfullt, särskilt när det kommer till applikationer som kräver en hög grad av 3D-grafik. Eftersom Silverlight är utformat som ett plugin finns det enbart en delmängd av funktionaliteten i det kompletta .NET-ramverket att tillgå. Bygger man Silverlight applikationer får man alltså nöja sig med en avskalad programmeringsfunktionalitet inom både gränssnittet och .NET-ramverket (Silverlight Overview, 2010) Webbläsare som stödjer Silverlight Opera 9.64, Google Chrome, Internet Explorer 8, Mozilla Firefox 3.0, Mozilla Firefox 3.5.
En Silverlight-applikation följer inte Click-Once-modellen utan använder sig av en säkerhetsmodell baserad på .NET-ramverkets ”transparanta modell”. Denna modell delar upp applikationen i tre lager som syns i figur 2.11 nedan. All den kod en utvecklare skriver själv är applikationskod och tillhör det transparenta lagret. Detta lager är isolerat från den
TEORI
20
lokala datorn och körs i "sandlådan". Vill applikationskoden komma ur begränsningarna som det transparenta lagret medför måste den anropa det "säkerkritiska"-lagret. Det "säkerkritiska"-lagret anropar då det kritiska lagret som i sin tur har möjlighet att utföra mer plattformsrelaterade ärenden som skrivning till filsystemet med mera. Syftet med det säkerkritiskalagret är att validera så att kritiska funktioner anropade av användaren inte är tveksamt utförda (Silverlight Application Security Model,2010). Figur 2.11. Den transparenta säkerhetsmodellens lager.
Det finns två lägen man kan köra en Silverlight applikation i, det är i webbläsaren eller i ett läge som kallas ”utanför webbläsaren”. Väljer man att köra applikationen i webbläsaren får man de begränsningar som är satta där. Om man istället väljer alternativet ”utanför webbläsaren” har man möjlighet att utöka interaktionen med den lokala datorn. Dessa utökade interaktionsmöjligheter är:
Total åtkomst till tangentbordet under helskärmskörning.
Direktåtkomst till användarens lokala dokumentmappar.
Möjlighet att interagera med hårdvaran.
Inga begränsningar till vilka hemsidor eller webbtjänster man har åtkomst till. Silverlight uppdaterar också automatiskt en ”utanför webbläsaren”-applikation varje gång den startas (Silverlight Application Security Model, 2010).
TEORI
21
2.5 Teknologistack för applikationsnivån (nivå två)
Det här avsnittet fokuserar på hur man kan beskriva databaserna i form av objekt, vilket kommer användas av webblösningen som undersöks i senare kapitel.
2.5.1 Object Relational Mapping (ORM)
Mellan databaserna och affärslogiken kan man använda ett lager kallat dataåtkomstlagret där man brukar representera den data man ser från databasernas synvinkel till något som affärslogiklagret förstår. Detta kan till exempel vara att man från databasens synvinkel endast ser tabeller och data medan man ur affärslogikens synvinkel vill se dessa som objekt istället. Det är denna typ av matchning mellan databas- och affärslager som dataåtkomstlagret möjliggör. Fördelar med att använda sig av en ORM-teknik (McCafferty, 2006):
Det låter en utveckla persistenta klasser samt persistent logik utan att behöva bry sig om hur man ska hantera data.
Hjälper utvecklaren genom att fria denne från mycket av persistent datarelaterad programmering.
Minimerar komplexiteten i övergången mellan databaslagret till affärslogikslagret genom att omsluta databastabellerna med givna relationer till något som affärslogiken förstår.
Det finns redan färdiga tekniker som man kan använda till detta, dessa beskrivs nedan.
2.5.2 Hibernate (NHibernate)
Hibernate är utvecklat för Java men principen är densamma för portningen NHibernate som är för .NET-ramverket. I denna implementation har man valt att skapa länkar mellan objekten som ska skapas och databaserna. Dessa länkar är i form av XML-filer där man beskriver vilken tabell i databasen samt vilket attribut ett objekt ska länkas till. Genom denna XML-fil kan sedan Hibernate skapa ett kodskelett som speglar hur ett objekt motsvarande en viss rad i en databastabell ser ut. I dessa objektinstanser kan man sedan ändra det som är nödvändigt innan man bestämmer sig för att uppdatera dem, ta bort dem eller lägga till dem i databasen (McCafferty, 2006). Det enklaste sättet att skriva de länkande XML-filerna är om man låter relationen vara en till en, det vill säga ett objekt för varje rad i en databastabell. Det finns möjlighet att göra dessa XML-länkningar mer komplicerade. Det kan till exempel vara att man vill åstadkomma likadana relationer mellan sina objekt som det finns mellan databastabellerna. Det finns stöd för detta i Hibernate. Det finns alltså möjlighet att använda transaktioner, en-till-en mappning, en-till-flera mappning samt flera-till-flera mappning. Figur 2.12 visar en bild på Hibernates placering i applikationsarkitekturen.
TEORI
22
Figur 2.12. Bild på Hibernates placering i arkitekturen.
Istället för att använda sig av XML-länkning kan man skapa sina objektklasser själv och mappa dessa till Hibernate genom användandet av annoteringar. En annotering talar om för en metod i klassen att den är länkad till ett visst attribut i en databastabell (McCafferty, 2006). HQL HQL (Hibernate Query Language) är ett frågespråk likt SQL som är utvecklat för att hjälpa till med förfrågningar mot den konceptuella datamodellen som Hibernate skapar. Med HQL frågar man efter objekt med en viss typ av kriterium (McCafferty, 2006).
2.5.3 ADO.NET Entity Framework
Detta ramverk är utvecklat av Microsoft och fyller samma syfte för .NET som Hibernate gör för Java. Det vill säga man använder sig av entiteter och entitetsmängder för att göra en abstraherande modell över relationsdatabasens tabeller och relationer. Dessa abstraherande modeller (kallat EDM - Entity Data Model) utformas med ett verktyg i Visual Studio. Det som skapas i bakgrunden när man gör dessa modeller är XML-filer precis som med Hibernate. Med detta verktyg behöver, i de flesta fall, inte utvecklaren bry sig om XML-filerna som skapas utan kan koncentrera sig på modellen. Fördelen med dessa modeller är att komplexiteten hos den ofta normaliserade databasen minimeras. Ett exempel kan vara denna databas (visas som relationsdatabas i figur 2.13 samt som den abstraherande modellen i figur 2.14):
TEORI
23
Figur 2.13. Normaliserat schema i databasen (The ADO.NET Entity Framework Overview, 2010).
Figur 2.14: Den abstraherande modellen (The ADO.NET Entity Framework Overview, 2010).
Fördelen med den abstraherande modellen är att den tar bort komplexiteten som en normaliserad databas oftast har. Det vill säga istället för att skriva koden för att länka ihop olika databastabeller med varandra kan med hjälp av modellen abstrahera detta och möjligen i förlängningen få en modell som representerar första normalformen. Till exempel kan en förfrågning till modellerna se ut så här i respektive fall: Normaliserad databas SELECT sp.FirstName, sp.LastName, sp.HireDate FROM SalesPerson sp INNER JOIN Employee e ON sp.SalesPersonID = e.EmployeeID INNER JOIN Contact c ON e.EmployeeID = c.ContactID WHERE e.SalariedFlag = 1 AND e.HireDate >= '2006-01-01' Den abstraherande modellen SELECT sp.FirstName, sp.LastName, sp.HireDate FROM AdventureWorks.AdventureWorksDB.SalesPeople AS sp
TEORI
24
WHERE sp.HireDate >= '2006-01-01' I Entity Framework finns det också objekttjänster som gör det möjligt att arbeta enbart mot .NET-objekt. Dessa objekt är kopior av entiteterna som de representerar. Detta förhållningssätt har utvecklats för att ytterligare minimera skillnaden mellan databaslagret och affärslogikslagret. Istället arbetar man mot dessa objekt som man då kan utföra normala operationer på så som uppdatering, insättning och borttagning. En fördel med detta är att man med enkelhet i ett klient/server-scenario kan serialisera dessa objekt och skicka till klienten. Klienten kan sedan deserialisera dessa och därmed erhålla en säker och enkel kommunikation. Hur klienten begär dessa databasobjekt från servern görs enklast med olika typer av tjänster som beskrivs senare i denna teoridel (The ADO.NET Entity Framework Overview, 2010). LINQ to Entities / Entity SQL Det finns olika varianter av frågespråk att använda mot denna abstraherande modell. Fördelen med att använda ett av dessa språk är att man kan arbeta direkt mot objekt och inte behöver använda komplexa SQL-satser i förfrågningar mot databasen.
TEORI
25
2.6 Teknologistack för kommunikation mellan klient och server
Syftet med det här avsnittet är att undersöka vad som finns att tillgå i .NET-ramverket när det gäller kommunikationen mellan klient och server. I senare kapitel kommer webblösningen som studeras att använda sig av webbtjänster.
2.6.1 WCF
Innan WCF (Windows Communication Foundation) kom till fanns det en rad olika protokoll och tekniker man kunde använda för att kommunicera med tjänster emellan en klient och en server. Dessa tekniker kunde till exempel vara baserade på SOAP (Simple Object Access Protocol) eller REST (Representational State Transfer). Inte nog med det man var även tvungen att bestämma hur dessa tekniker skulle kommunicera över nätverket med till exempel HTTP, TCP, UDP eller MSMQ. WCF är designat till att kapsla dessa många val och leverera en lösning som fungerar oavsett hur de underliggande teknikerna ser ut. Arkitekturen i WCF gör detta med såkallade "kanaler" och "bindningar". En kanal kan ses som någonting en applikationstjänst måste gå igenom för att kunna komma ut på nätverket. En sådan kanal kan till exempel stå för att kapsla in ett meddelande som ska skickas i en SOAP-teknik eller helt enkelt göra det redo för att sändas via TCP över nätverket. Det kan finnas flera kanaler ovanpå varandra som en applikationstjänst måste gå igenom (Understanding WCF Communication, 2010). Har man studerat TCP/IP-stacken kan man tänka på samma sätt om kanaler som man tänker på lager där. Figur 2.15 visar konceptet. Figur 2.15. Bild över WCF arkitekturen.
Vill man nu använda dessa kanaler i en tjänst gör man detta genom en så kallad "bindning". En bindning är ett sätt att gruppera ihop ett antal kanaler, genom att göra detta skapar man en slags kanalstack. Det finns flera redan tillgängliga kanalstackar som till exempel "BasicHttpBinding". En annan tillgänglig bindning är "NamedPipeTransport" som stöder interprocesskommunikationen inom en och samma dator. Det går att själv definiera sin egen bindning och därmed kanalstack (Understanding WCF Communication, 2010). I WCF-ramverket skapar man tjänster som utomstående klienter kan konsumera. Varje tjänst exponerar sig mot omvärlden med "End points" och en tjänst kan ha flera stycken "end points" som klienter kan komma åt. Det finns tre olika beståndsdelar i ett sådant, dessa är kontrakt, adress och bindning. Kontraktet beskriver vilka metoder som exponeras och vad de
TEORI
26
metoderna hanterar för in- och utparametrar. Adressen beskriver vart tjänsten exponerar sin funktionalitet och bindningen beskriver hur kommunikationen mellan klienten och tjänsten ska utföras (Understanding WCF Communication, 2010). För att skapa en tjänst kan man följa stegen nedan.
Definiera ett kontrakt som man sedan implementerar.
Definiera en bindning samt tjänstens exponeringsadress.
Definiera "end points" samt bestämma hur tjänsten ska hostas.
Det sista man gör är att implementera klienten.
Kontrakt Kontrakt i WCF är ett interface annoterat med [ServiceContract] samt de ingående metoderna med [OperationContract]. Detta interface implementeras sedan för att få den funktionalitet som önskas. Det som kommuniceras mellan en tjänst och en klient är sedan dessa interface (kontrakt). Normalt sett kan man bara använda primitiva typer med dessa kontrakt men vill man använda egentillverkade typer får man definiera dessa klasser med [DataContract] samt varje publik del med [DataMember] (Understanding WCF Communication, 2010). Bindning och adress Bindningar är, som beskrivet innan, en kanalstack över hur tjänsten kommer kommunicera över nätverket. I detta steg väljer man även vilken adress som tjänsten ska exponeras ifrån. End point Efter att man definierat vad tjänstens "End point" ska exponera för kontrakt, kanalstack samt adress har man ett antal möjliga värdprocesser att välja emellan. Det går till exempel att använda Microsoft Internet Information Server eller helt enkelt välja en redan existerande process genom att använda dess "ServiceHost-klass" (Understanding WCF Communication, 2010). Ett exempel på ett "end point": <endpoint address="http://www.test.com/AccountAccess/Accounts.svc" binding="basicHttpBinding" contract="IAccount"/>
Klient Sist men inte minst implementerar man klienten och bestämmer där hur man ska kommunicera med tjänsten samt var tjänsten finns att tillgå. Man kan göra detta automatiskt med diverse program från Microsoft men enklast är att man använder Visual Studio, där det finns möjlighet att använda ett menyalternativ ”Add Service Reference” som åstadkommer det direkt. Visual studio kan också, automatiskt, skapa en egen testklient för att utvecklaren ska kunna testa sina tjänster. Det som är bra med Windows Communication Foundation är att man har ett stort antal möjliga tekniker att välja emellan när det gäller transport och bindningar. Detta gör att man
TEORI
27
som systemarkitekt eller utvecklare kan kombinera dessa, för att uppfylla kraven, samtidigt som programmeringsmodellen kommer att vara densamma, vilket är en fördel om man jämför med tidigare tekniker.
2.6.2 WCF RIA Services
Microsoft har utvecklat ett ramverk som förenklar utvecklingen av N-lager-applikationer. Detta ramverk går under namnet WCF (Windows Communication Foundation) RIA (Rich Internet Application). Ramverket koncentrerar sig på utvecklingen av den del av applikationen som ligger emellan dataåtkomstlagret och presentationslagret som syns i figur 2.16.
När man bygger en seriös affärsapplikation tillsammans med en rik teknik för användargränssnitt, som Silverlight, bearbetar man ofta mycket data. Försöker man skriva en klient/server applikation själv kommer man att behöva arbeta mycket med att försöka få data från databaserna till klienten och alla tekniker som hör där till. Detta ramverk löser det här åt en och gör så att utvecklaren kan fokusera på vilken data som behövs samt manipulation och presentation av denna data i klienten. Ramverket löser även många av de problem som utvecklare av flerskiktade lösningar stöter på, dessa är till exempel hur man ska hantera autentisering, auktorisering, datavalidering och filtrering samtidigt som applikationen ska vara enkel att testa och underhålla.
Figur 2.16. Vad WCF RIA Services fokuserar på.
Ramverket fungerar genom att använda så kallade domäntjänster som tillhandahåller tjänster till klienterna. Till exempel kan man ha en tjänst som tar fram all data ur en viss tabell och gör den tillgänglig för klienten. Klienten kommer då få denna data i sitt domäntjänstobjekt och därigenom kunna till exempel använda den för presentation. Domäntjänsten har koll på objektet och vad som händer med detta och man kan därigenom uppdatera objektet via klienten och distribuera ner detta i databasen via servertjänsten. Det finns inget officiellt stöd av RIA Services för någon annan teknik än Silverlight hos Microsoft ännu (WCF RIA Services, 2010). Ett par grundläggande definitioner som används i ramverket som förklarar lite hur det hänger ihop (WCF RIA Services, 2010):
Projektlänkar – En länk mellan klienten och servern samt tillhörande bibliotek. Fördelen med detta är att domäntjänster, entiteter med mera som finns på serversidan skapas automatiskt på klientsidan. Tjänstekommunikationen fungerar därför automatiskt.
TEORI
28
Domäntjänster – kärnkonstruktionen i WCF RIA Services. En domäntjänst definierar operationer som finns tillgängliga hos serversidan.
Entiteter – finns beskrivet ovan i teoridelen. Huvudfunktionen är att få en gemensam datatyp som kan serialiseras/ deserialiseras mellan server och klienten. Dessa är med fördel skapade med Entity Framework tillsammans med LINQ to SQL.
Domänkontext – klientens motsvarighet av serverns domäntjänster. Detta består av genererad kod på klientsidan som ger en åtkomst till funktionaliteten som finns hos servern. Internt består denna av en WCF-proxy som hanterar serviceanrop samt håller koll på entiteterna hos klienten.
DomainDataSource – ihopkopplad med domänkontextet. Används till att utföra förfrågningar samt begära dataändringar på serversidan. Genom denna kan man också binda direkt via XAML (Extensible Application Markup Language) som används av bland annat gränssnittstekniken WPF.
2.6.3 Bygg det själv
Möjligheten finns att bygga ett eget kommunikationsbibliotek och inte alls ta hjälp av redan tillgängliga ramverk. Dock är det enklare att utgå från dessa ramverk.
METODIK
29
Kapitel 3
Metodik och grund till arbetet I det här kapitlet beskrivs och motiveras metodvalen för arbetsgången, det vill säga hur det har varit upplagt och strukturerat. En grund till arbetet läggs också, för att man ska ha något att ”hänga” upp det som gås igenom i senare kapitel på.
3.1 Arbetsmetod och teknikbegränsningar
Arbetet har börjat med en omfattande litteraturstudie kring området att bygga webblösningar med .NET-ramverket. I denna fas har det även ingått att sätta sig in i diagnosprogrammet samt hur det är uppbyggt. Syftet med studien har varit att få ett grepp om vad .NET-ramverket har att erbjuda teknikmässigt, för att sedan kunna undersöka vilka av dessa tekniker som passar för ett onlinebaserat diagnosprogram. Under studien har jag också dragit slutsatsen att diagnosprogrammet består av två huvuddelar, där den ena delen har uppgiften att läsa data från databaserna och den andra delen att läsa data från fordonet. Databaserna är också det som tar mest hårddiskutrymme (ungefär 230MB utav det totala 340MB) och därför har jag ansett att ett lämpligt första steg, mot ett onlinebaserat diagnosprogram och en tunn klient, vore att studera hur ett diagnosprogram med databaserna på en extern server skulle kunna tänkas fungera. Den webblösning (tekniker, arkitektur med mera) som detta utmynnar i ska också vara kompatibel med ytterligare uppflyttningar av diagnosprograms funktionalitet från klienten till servern. Detta uppfyller också kravet på att kunna uppdatera databaserna utan att behöva uppdatera klientens programvara. Genomförandet har utgått från företagets arbetssätt, som är Scrum (en iterativ metod). I detta fall har det inneburit att kontinuerligt rapportera hur arbetet fortskrider samt informera om problem som kan ha uppstått. Arbetets fokus ligger alltså på att studera hur man ska separera dagens databaslager från affärslogiken i en webbarkitektur samt hur dagens Microsoft Access databaser som ligger lokalt fungerar på en extern server. Arbetet ger ett förslag på hur en fysisk arkitektur, som har databaserna på en extern server, kan se ut i verkligheten och hur man kan bygga en webblösning, som uppfyller kraven, kring konceptet. Det sekundära fokuset ligger på hur man generellt, utifrån de krav som finns på diagnosprogrammet, kan tänkas dela upp arkitekturen ytterligare (med hänsyn till en tunn klient). De tekniker som används/undersöks under arbetet med ett onlinebaserat Scania Diagnos ligger inom .NET, mer specifikt har jag valt att titta på (tre-nivåers arkitektur):
För klienten (presentationsnivån): En delmängd av dagens diagnosprogram (använder sig av WPF) med Click-Once av den enkla anledningen att det är teknikvalet med minst restriktioner och kräver minst anpassning av diagnosprogrammet. Det finns till exempel krav på återanvändning av kod, möjlighet att komma åt hårdvara och stora delar av filsystemet. Skulle man istället valt att använda Silverlight hade man fått nöja sig med
METODIK
30
ett begränsat .NET-ramverk med den följden att det blir svårt att föra över komponenter som redan är skrivna. Med Silverlight hade man också fått nöja sig med flera säkerhetsrestriktioner än Click-Once, vilket finns beskrivet i avsnitt 2.4.3. Alternativet att använda WPF XBAP är också möjligt, det enda som skiljer sig från WPF Click-Once är att applikationen körs i webbläsaren och därmed får ett antal restriktioner kring hur det grafiska gränssnittet kan interagera med användaren (finns beskrivet i avsnitt 2.4.2).
För kommunikationen mellan klient och server: WCF istället för WCF RIA Services då de senare är utvecklat för Silverlight och inte för resterande .NET-tekniker. WCF (och WCF RIA) är också en väldigt kompetent webbtjänstteknik, som finns beskrivet i avsnitt 2.6.1, vilket är en fördel i och med att man enkelt kan åstadkomma en säker anslutning mellan klient och server.
För servern (applikations- och databasnivån): Entity Framework istället för NHibernate. Anledningen till detta är att Entity Framework finns integrerat i Microsoft Visual Studio 2010 samt att det är en av Microsofts egna ramverkskomponenter, vilket gör att man har ett erkänt företag att förlita sig på. Entity Framework har också många fördelar i onlinebaserade scenarion i och med att Microsoft Visual Studio 2010 har inbyggt stöd för distribuering av entiteter mellan klient och server. Jag har även valt att i min undersökning studera om man skulle kunna tänkas använda diagnosprogrammets nuvarande resurslager för att med säkerhet uppfylla kravet på att det ska gå att återanvända kod. Till databasnivån har jag valt Microsoft SQL Server i och med att det är en erkänd databashanterare som stödjer bland annat flera användare simultant, vilket krävs av en framtida onlinelösning.
3.2 Scenariot
Syftet med arbetet är att leverera ett förslag på hur ett onlinebaserat diagnosprogram kan se ut med hänsyn till de krav som ställs. Man vill då kunna testa webblösningsförslaget på ett någorlunda riktigt sätt, och jämföra det med dagens "stand-alone"-diagnosprogram. Eftersom arbetet fokuserar på hur en arkitektur med databaserna på en extern server ser ut, har jag valt uppkopplingsscenariot som testscenario. Anledningen till detta är att uppkopplingsscenariot är det moment i diagnosprogrammet som har absolut mest interaktion med databaserna. I det scenariot kommer all data att hämtas från fordonets styrenheter samt all data att hämtas från databaserna. Uppkopplingsscenariot Uppkoppling är ett scenario där man kombinerar utläsning av styrenhetsinformation med information från databaserna för att kunna presentera individanpassad information och tillhandahålla diagnos- och programmeringsmetoder som är tillämpliga för just det fordon man för närvarande är uppkopplad mot. En bild på hur scenariot ser ut i SDP3, ses i figur 3.1.
METODIK
31
Figur 3.1. En bild på hur en uppkoppling mot ett fordon ser ut i SDP3.
Under flertalet av momenten som ses i bilden ovan kommer data att hämtas från databaserna.
3.3 Arkitekturer
Det finns två huvudarkitekturer som jag har valt att inrikta arbetet på, nämligen en arkitektur där man väljer att använda Entity Framework som dataåtkomstlager och en arkitektur där man låter nuvarande resurslager användas som dataåtkomstlager. Anledningen till att dessa arkitekturer studeras är att man, i ett onlinebaserat scenario med databaserna på en extern server, inte vill exponera databaserna (Microsoft SQL Server) direkt mot omvärlden utan gärna vill ha ett mellanlager som "skydd". Man vill alltså aldrig exponera det oftast mest värdefulla i sitt program, nämligen databasinformationen, och riskera att få denna korrupt. Det som exponeras mot omvärlden är istället webbtjänster med fördefinierad funktionalitet. Kommunikationen mellan klienten och servern görs med Windows Communication Foundation för att via webbtjänster ge tillgång till databaserna via någon av dataåtkomstteknikerna. Ett mellanlager krävs också för att utnyttja en tre-nivåers arkitektur (avsnitt 2.1.3) och därmed åstadkomma högre skalbarhet samt att minska risken att systemet hamnar i konceptet "single-point-of-failure". En viktig fördel med att exponera ut objekt via, i detta arbete, antingen nuvarande resurslager eller Entity Framework är att klienterna då begär just objekt, och inte till exempel svar på SQL-satser, vilket gör att klienten inte blir beroende av hur den underliggande databasmodellen ser ut. Kommunikationen mellan klienten och servern består då inte heller av SQL-satser vilket gör det svårare för inkräktare att ta reda på hur databasstrukturen ser ut. En logisk modell, som beskriver arkitekturerna som studeras, ses i figur 3.2.
METODIK
32
Figur 3.2. Arkitektur med antingen Entity Framework eller nuvarande resurslager. WCF används som webbtjänstteknik mellan klienten och servern och exponerar metoder till något av dataåtkomstlagren.
Arkitektur nummer ett bygger på att man använder sig av Entity Framework för att konceptualisera databaserna. Arkitektur nummer två bygger på att man använder sig av en modifikation av nuvarande resurslager. Båda arkitekturerna ger en klientversion av SDP3 tillgång till databaserna via webbtjänster med tekniken WCF. Klientversionen av SDP3 kommer att finns att tillgå via distribueringstekniken Click-Once, vilket dock inte syns i figuren.
3.4 Upplägg och prototyp
De olika delmomenten som ingår i genomförandet beskrivs nedan. Samla in krav på dagens diagnosprogram Insamling av krav på dagens diagnosprogram har skett för att få grepp om vad som gör just detta diagnosprogram unikt. Utifrån dessa krav har de tänkta arkitekturerna analyserats och den valda realiserats. Implementera ett program som simulerar uppkopplingsscenariot För att testa både hur bra dagens "stand-alone"-lösning fungerar och hur bra mitt onlinebaserade förslag fungerar, så har det implementerats ett program som efterliknar uppkopplingsscenariot. Detta program har utvecklats så att jag på ett smidigt sätt, utan att ändra i diagnosprogrammets kodbas, ska kunna testa mina lösningar. En begränsning i programmet är att det bara efterliknar anropen till databaserna och inte anropen till fordonet. Microsoft SQL Server istället för dagens Microsoft Access Ett första steg i att realisera min tänkta onlinebaserade arkitektur är att studera hur databaserna och resurslagret fungerar om man använder Microsoft SQL Server istället för
METODIK
33
nuvarande lösning med Microsoft Access. Även hur bra skalbarhet, klientmässigt, det blir med Microsoft SQL Server tillsammans med nuvarande resurslager undersöks. Arkitekturer Här kommer det två logiska arkitekturerna (antingen med Entity Framework eller nuvarande resurslager) att undersökas och diskuteras. Här gås även den fysiska arkitekturen igenom och därmed också hur man kan använda Click-Once för att distribuera resterande del av diagnosprogrammet. Implementera prototyp En prototyp som beskriver konceptet med den arkitektur (webbtjänster som antingen exponerar metoder till nuvarande resurslager eller till Entity Framework) som anses vara lämpligast implementeras. Denna prototyp modifierar programmet som efterliknar uppkopplingsscenariot till att använda WCF med lämplig arkitektur. Prototypen ska efterlikna uppkopplingsscenariot, det vill säga läsa data från databaserna och visa detta för användaren. Följande begränsningar är satta:
Bara implementera själva uppläsningen ur databasen och inte resterande funktionalitet så som kommunikationen med fordonet etcetera.
Utvecklingen sker i .NET med C#, gränssnittstekniken WPF och kommunikationstekniken WCF.
Hur denna prototyp står sig mot dagens diagnosprogram undersöks och även hur bra skalbarhet prototypen har undersöks. Analysera, dra slutsatser och framtida rekommendationer En analys av samtliga moment i genomförandedelen utförs. Denna analys utmynnar i rekommendationer för framtiden.
KRAVINSAMLING OCH REFERENSTESTER
34
Kapitel 4
Kravinsamling och referenstester Detta kapitel är avsett att ta reda på vilka krav som ställs på dagens diagnosprogram samt vilka krav som ställs på ett onlinebaserat diagnosprogram. Ett antal tester utförs för att skapa referensvärden som den webbtjänstbaserade arkitekturen, berörd i kapitel sex, jämförs med.
4.1 Kravinsamling
För att kunna få en grund till arbetet har jag undersökt vilka krav som ställs på både dagens diagnosprogram samt vilka krav som tillkommer för ett onlinebaserat alternativ. Dessa krav har sedan använts för att realisera den onlinebaserade arkitekturen och för att analysera den och ge framtida rekommendationer. Kravinsamlingen har skett med hjälp av diskussioner samt en grundläggande genomgång av materialet kring diagnosapplikationen. De framtagna kraven listas i punktform nedan: Allmänna krav (i dagens lösning):
Realtidskommunikation med fordonet.
Läsa ut information från databaserna så att den på ett eller annat sätt går att visa i realtid under till exempel en felsökning.
Externa komponenter (till exempel .DLL bibliotek) ska gå att använda och uppkoppling till andra tjänster över Internet.
Uppkopplingen till fordonet ska gå relativt snabbt.
Man ska kunna interagera till fullo med den lokala datorn programmet finns installerat på, till exempel använda USB-autentisering, koppla datorn till fordonet med ett VCI eller på godtycklig plats spara data.
SCOMM (Scania Communication Module) är inte trådsäker och stödjer enbart en "användare".
Databaskrav (i dagens lösning):
Endast en användare.
Inga krav på transaktionshantering.
Förhållandevis små datamängder.
Enbart läsningar.
Inga avancerade sökningar mot databasen.
Enkel och tydlig spårbarhet mellan modell, kod och databas.
Det ska vara lätt för en utvecklare att lägga in nya typer i databasen.
Inga runtime-licenser vid installation hos användare.
Möjlighet att mata in data i databaserna med hjälp av XML-schema.
Referenser till bilder är statiska och pekar på datorns hårddisk.
KRAVINSAMLING OCH REFERENSTESTER
35
Återstående krav på ett Scania Diagnos för webben:
Säkerhet över Internet (använda en mjukvarunyckel istället för en hårdvarunyckel).
Servern och databasen måste vara multitrådad och kunna hantera flera anslutningar samtidigt.
Skalbarhet och prestanda, det vill säga att det kanske inte är möjligt att läsa upp samtlig information i databasen direkt (som man gör i dagens lösning) utan man får läsa efterhand som det behövs.
Referera till hjälpbilder samt andra resurser genom servern.
Klienten har tillgång till ett gränssnitt med WCF istället för nuvarande resursgränssnitt.
Krav på realtidskommunikation mellan server, klient och fordon.
Möjlighet att uppgradera klientens programvara på avstånd.
Uppdatera databaserna utan att klienterna ska behöva uppdateras.
Återanvändning av kod.
Den onlinebaserade lösningen ska gå att distribuera som en "stand-alone"-lösning, för att felsökningar utan tillgång till Internet ska gå att genomföra.
4.2 Efterlikna ett riktigt uppkopplingsscenario
För att kunna testa de lösningar som undersöks har jag utvecklat ett program som efterliknar ett riktigt uppkopplingsscenario. Scenariot har valts eftersom det, i diagnosprogrammet, är där det mesta av databasinteraktionen görs. Genom att i diagnosprogrammet lägga till funktionalitet som loggar all interaktion (anrop till metoder etc.) mot resurslagret under en uppkoppling, så har man därigenom möjlighet att se exakt vad som hänt i diagnosprogrammet med hänsyn till databaserna. En sådan loggfil innehåller alla anrop till de metoder i resurslagret som en uppkoppling resulterar i. Ett exempel på en sådan loggfil ses i figur 4.1.
Figur 4.1. En del av en loggfil. Värdena beskriver databas, instans och typ som SDP3:s metoder i resurslagret använder sig av när de hämtar data i databaserna.
KRAVINSAMLING OCH REFERENSTESTER
36
För att kunna efterlikna anropen som sker till databaserna har resurslagret lyfts ur det riktiga diagnosprogrammet. Jag utvecklade ett program som använder sig av det urlyfta resurslagret som tillsammans med en godtycklig loggfil användes för att simulera ett verkligt uppkopplingsscenario, utanför diagnosprogrammet. I det urlyfta resurslagret har jag lagt till funktionalitet för att stödja Microsoft SQL Server, eftersom att det stödet inte fanns i sin ursprungsform innan. Jag gjorde sedan så att man automatiskt i programmet kunde välja om man ville efterlikna uppkopplingsscenariot med antingen Microsoft Access eller Microsoft SQL Server. I programmet väljer man den loggfil som man vill läsa ifrån för att efterlikna uppkopplingsscenariot samt vilken databashanterare man vill använda. När man sedan trycker på knappen "Perform" kommer uppkopplingsscenariot att köras fem gånger efter varandra (de fem översta tidsboxarna) samt en medeltid av dessa fem tider att visas i den understa tidsboxen. En bild på programmet kan ses i figur 4.2. Figur 4.2. Programmet som testar databasernas prestanda. Bilden visar fem mätvärden samt ett medelvärde i sekunder för hur lång tid ett uppkopplings- scenario med en given loggfil tar.
Det data som en loggfil baseras på är hämtad från en uppkoppling i diagnosprogrammet mot en så kallad "demofil". En demofil kan enkelt beskrivas som en ögonblicksbild som blivit inspelad från ett fordon och dess styrenheter. Denna bild innehåller alla specifika styrenhetsvärden. Till exempel kan man spara ner information från ett fordon med en felaktig styrenhet, för att testare av diagnosprogrammet senare ska kunna validera att programmet fungerar. Väljer man att köra en demofil i diagnosprogrammet kommer det resultera i att programmet reagerar på samma sätt som vid utläsning av data från ett riktigt fordon. Den enda skillnaden är att "SCOMM", istället för att läsa från ett fordon, läser och tolkar data direkt från en textfil. En överblick över det som beskrivs i det här avsnittet kan ses i figur 4.3.
KRAVINSAMLING OCH REFERENSTESTER
37
Figur 4.3. Överblickande bild för mer förståelse av vad som sker.
I de senare testerna har jag använt demofiler för att simulera olika fordon med ett varierande antal styrenheter. Programmet, i figur 4.2, används i avsnitt 4.3 nedan för att testa prestandan hos nuvarande databaslösning (Microsoft Access) samt prestandan om man byter ut databashanteraren mot Microsoft SQL Server och (modifierat) i kapitel sex för att testa prestandan hos webbtjänstslösningen.
4.3 Referenslösning och tester
De två referenslösningar jag har valt att titta på är dagens lösning med Microsoft Access och en lösning där man byter ut databashanteraren mot Microsoft SQL Server som körs över intranätet. Anledning till att jag jämför dessa två alternativen är att ett första steg mot en onlinebaserad arkitektur är att använda sig av Microsoft SQL Server istället för Microsoft Access. Det egenutvecklade programmet (figur 4.2) användes för att simulera de anrop till resurslagret och databaserna som en demofilskörning resulterade i ovan. Resultaten, som ses i figur 4.4 nedan, är menade att ha som referenser att jämföra den mer komplicerade arkitekturslösningen, som berörs i kapitel sex, med. Testerna visar tiden det tog att koppla upp sig och hämta all data från databaserna under ett uppkopplingsscenario. Testet med Microsoft Access är gjord mot den lokala datorn medan en del av testerna mot Microsoft SQL Server är gjorda mot en server tillgänglig via intranätet, för att testa skalbarheten. Alla tester är baserade på samma demofil och en medeltid finns för varje test. För utförligare information om testresultaten hänvisar jag till bilaga 1. Dessa tester visar vad man kan förvänta sig för maximal prestanda med den onlinebaserade arkitekturen i och med att referenslösningen med Microsoft SQL Server är den minsta delmängden av den onlinebaserade lösningen. I testerna körs alla klienter på samma dator. För att få en uppskattning av hur lång tid som en klient tar på sig när servern är belastad med ett antal andra klienter, så har alla klienter startats samtidigt och därifrån en medeltid över samtliga tagits.
KRAVINSAMLING OCH REFERENSTESTER
38
Testuppsättning Klient(er) Dator: Intel Xeon, W3520 @ 2.67GHz, 3.50GB Ram. Anslutningen var lokalt nätverk 100Mbit. Server (ej samma dator som klienten) Dator: Intel Xeon, W3520 @ 2.67GHz, 3.50GB Ram. Anslutningen var lokalt nätverk 100Mbit. Tester Microsoft Access Lokal maskin (klient och server på samma dator): 4.7s Microsoft SQL Server Lokal maskin (klient och server på samma dator): 2.9s 1 klient mot en server: 4.3s 2 klienter mot en server: 4.4s 3 klienter mot en server: 4.7s 6 klienter mot en server: 5.7s 10 klienter mot en server: 6.9s
Figur 4.4. Medeltider för de olika testfallen i sekunder. Benämning SQL betyder att mätningen skett mot Microsoft SQL Server. De två första staplarna är mätningar gjorda mot den lokala dator medan de resterande är gjorda mot en Microsoft SQL Server belägen på en annan dator.
Här nedan i figur 4.5 ses en tidsutvecklingsgraf över hur mycket tiden ökar med antalet anslutna klienter som kör uppkopplingsscenariot mot en Microsoft SQL Server belägen på intranätet. Alla klienter körs på samma dator.
0
1
2
3
4
5
6
7
8
Access (lokal maskin)
SQL (lokal maskin)
SQL (1 klient) SQL (2 klienter)
SQL (3 klienter)
SQL (6 klienter)
SQL (10 klienter)
S
e
k
u
n
d
e
r
Medeltider
KRAVINSAMLING OCH REFERENSTESTER
39
Figur 4.5. Graf över hur tiden ökar med antalet klienter som kör uppkopplingsscenariot mot en Microsoft SQL Server belägen på intranätet.
Mängd data som läses En uppskattning av hur stor mängd data som skickas mellan en klient och en server under ett uppkopplingsscenario gjordes med två olika demofiler, en med ett litet antal styrenheter och en som innehöll ett stort antal styrenheter. Detta för att få två extremvärden både uppåt och neråt datamängdsmässigt. Mätprogrammet som användes var ”DU Meter”. Med programmet kan man enkelt vid en given tidpunkt mäta datamängden som ett program producerar. Resultatet blev att mellan 3MB och 7MB skickas och att man kan förvänta sig att i genomsnitt 5MB kommer behöva läsas från databasen i ett normalt uppkopplingsscenario.
0
10
20
30
40
50
60
70
80
1 klient 20 klienter 40 klienter 60 klienter 80 klienter 100 klienter
S
e
k
u
n
d
e
r
Tidsgraf
ARKITEKTURER
40
Kapitel 5
Arkitekturer I detta kapitel undersöks arkitekturerna som det onlinebaserade diagnosprogrammet kan tänkas använda sig av. Det första avsnittet behandlar hur den fysiska arkitekturen ser ut medan de resterande avsnitten behandlar vad man ska exponera för dataåtkomstteknik via webbtjänsterna samt hur diagnosprogrammet kan utnyttja sig av Click-Once.
5.1 Fysisk arkitektur
Den fysiska arkitekturen som den logiska modellen, beskriven i avsnitt 3.3 och figur 3.2, appliceras på ses i figur 5.1.
Figur 5.1. En bild på ett nätverk med en demilitariserad zon (DMZ) som man kan applicera den logiska arkitekturen på.
Med hänsyn till den logiska arkitekturen (med databaserna på en extern server och webbtjänster som exponerar åtkomstmetoder till dessa) innebär det att man placerar Microsoft SQL Server i det interna nätverket och en webbserver med webbtjänsterna i den demilitariserade zonen. Man exponerar också ut installationen av diagnosprogrammet genom distribueringstekniken Click-Once i denna zon. Fördelen med detta är att den demilitariserade zonen har kontakt med både det interna nätverket samt Internet medan anslutningar som kommer från Internet bara har kontakt med den demilitariserade zonen. Det vill säga att det enbart kommer vara webbservern i den demilitariserade zonen som kommer vara utsatt för attacker medan den riktiga databasservern håller sig oskadd i det interna nätverket. Rent konfigurationsmässigt löser man uppdelningen av zonerna med olika
ARKITEKTURER
41
subnät. Som ses i figur 5.1 ovan kommer också bilder och resurser som pekas ut av databaserna att ligga på servern i det interna nätverket och det kommer finnas en webbtjänst i den demilitariserade zonen för att komma åt dessa.
5.2 Arkitektur med Entity Framework
Detta avsnitt undersöker om man kan använda Entity Framework för att exponera ut databasmetoder via webbtjänster till diagnosprogramsklienten. Eftersom ett av kraven i ett onlinebaserat diagnosprogram är återanvändning av kod, så har jag tittat på om man skulle kunna tänkas byta ut diagnosprogrammets resurslager (dataåtkomstlager) mot Entity Framework utan för mycket omstrukturering och omprogrammering i det resterande programmet. Jag såg två sätt att angripa problemet på, det ena var att skapa de entiteter, så som man vill ha dem, direkt i modelleringsverktyget som finns i Microsoft Visual Studio 2010 och det andra var att försöka efterlikna den dataåtkomststruktur som dagens resurslager skapar (PLC-strukturen). Definiera entiteterna från början Det enklaste sättet att börja använda ramverket vore om man började från början och definierade databasentiteterna i modellverktyget som finns att tillgå i Microsoft Visual Studio 2010. Detta skulle innebära att ramverket själv, utifrån entiteterna, bestämmer hur den vill att databaserna ska se ut. Eftersom att ramverket själv bestämmer saker och ting ska se ut så kommer det att leda till en rad förändringar jämfört med dagens lösning (i och med att objektstrukturerna ändras, det vill säga PLC-strukturen):
Alla affärskomponenter som initierar sig med hjälp av den dataåtkomststruktur som finns idag skulle behöva skrivas om till att hantera den nya strukturen.
De program som matar in information till databaserna skulle behöva skrivas om för att stödja den nya strukturen.
Man skulle behöva lägga tid på att validera att ramverket verkligen skapat en optimal databasstruktur.
Efterlikna resurslagrets datastruktur Jag har även tittat på att försöka efterlikna dagens dataåtkomststruktur (PLC) samt databasstruktur med ramverket och har kommit fram till att det är nog möjligt att göra detta, dock krävs det stor kunskap inom både hur dagens databaser ser ut samt inom hur resurslagret skapar upp sina PLC:er. Det finns ingen begränsning när det gäller att lägga in databasstrukturen i ramverket men däremot finns det begränsningar om man vill få det kompatibelt med PLC-strukturen som dagens resurslager skapar. En sådan begränsning är att det, utan användning av ett frågespråk, inte går att representera en PLC och dess understrukturer iterativt med Entity Framework (i de försök som jag gjort). Lyckas man undkomma dessa begränsningar skulle det i teorin inte behöva betyda någon omstrukturering eller omprogrammering i affärskomponenternas affärslager alls. Hur exponera detta med webbtjänster? En av fördelarna med att använda sig av Entity Framework är att det finns inbyggt stöd för att distribuera över entiteterna från servern till klienten via webbtjänster. Man får då också metoder så som uppdatering, borttagning samt skapande av databasentiteter mellan klient och server. Servern måste också exponera ut en webbtjänst för att hämta databasbilder.
ARKITEKTURER
42
5.3 Arkitektur med nuvarande resurslager
I denna arkitektur använder man sig av det nuvarande resurslagret för att exponera ut metoder till databaserna via webbtjänster till diagnosprogramsklienten. Det som man exponerar är då helt enkelt de metoder i resurslagret som dagens diagnosprogram använder sig av, det vill säga GETPLC() och GETPLCS(). Fördelen med detta är att diagnosprogrammet inte behöver omstruktureras eller omprogrammeras eftersom programmet är byggt efter resurslagret. Hur exponera detta med webbtjänster? Resurslagret ligger på servern där man exponerar funktionerna GETPLC() och GETPLCS() mot klienten. Denna exponering görs med webbtjänster med tillhörande kontrakt. På klienten (resterande diagnosprogram) behöver det skapas ett resurslager som enbart innehåller webbtjänstkopplingar till metoderna som servern exponerar. Servern ska exponera, förutom metoderna GETPLC() och GETPLCS(), en metod för att hämta databasbilder som i dagens lösning refereras statiskt på den lokala datorn. Eftersom det som metoderna GETPLC() och GETPLCS() returnerar inte är rena dataobjekt (som krävs av WCF generellt om man använder sig av dess XML-serialisering) utan även innehåller metoder så måste man på något sätt lösa detta. En lösning är att helt enkelt ta bort alla metoder från dataobjekten som returneras och återskapa dessa generellt på antingen server eller klienten, till kostnaden av att man behöver skriva om affärskomponenterna i nuvarande diagnosprogram då dessa förlitar sig på att vissa av dem finns i PLC-objekten. En annan lösning är att låta resurslagret hos klienten enbart efterfråga den data som den behöver från serversidan. Sedan skapar och fyller klienten själv upp en datastruktur som är kompatibel med affärskomponenterna.
5.4 Diagnosprogrammet med Click-Once
Arbetet har inte berört hur distributionen av diagnosprogrammet med Click-Once kan tänkas fungera i sin fullständighet. Det har dock gjorts antaganden att det inte ska finnas några oöverkomliga problem, eftersom Click-Once är en distribueringsteknik för .NET-ramverket. Diagnosprogrammet idag består av kod skriven i både .NET-ramverket och i ”native”-kod, det vill säga plattforms- och operativsystemsspecifik kod. Dessa ”native”-bibliotek är dock inga problem att distribuera med Click-Once. Begränsningar som sätts säkerhetsmässigt är inte heller något problem i och med att man antingen kan välja att certifiera sin applikation eller specifikt själv sätta vad programmet kräver säkerhetsmässigt.
PROTOTYP
43
Kapitel 6
Prototyp och tester Detta kapitel beskriver prototypen med den webblösningsarkitektur jag har valt, även tester som efterliknar uppkopplingsscenariot har gjorts för att jämföra hur denna arkitektur står sig mot referensarkitekturen som finns beskriven i kapitel fyra.
6.1 Teknik- och arkitekturval för prototypen
Prototypen använder sig av WCF och för att få anslutningen till servern med webbtjänsten säker använder jag en kanalstack som bygger på SSL (Secure Sockets Layer). Detta innebär att all trafik som går mellan klienten och servern kommer att vara krypterad. För att klienten ska autentisera mot servern så använder jag mig av en egentillverkad användarnamn- och lösenordsvaliderare. Det finns många olika sätt att autentisera sig med WCF, till exempel genom Windows eller certifikat men jag valde ovanstående eftersom jag tror Scania kommer använda sig av det i framtiden. Anledningen till att jag tror att Scania kommer använda sig av en egentillverkad lösenordvaliderare är att de i framtiden kommer att gå över till en mjukvarubaserad autentiseringsnyckel och inte använda den fysiska USB-nyckel de använder idag. Jag valde att göra en prototyp med nuvarande resurslager eftersom det verkade mer rimligt än att göra en med Entity Framework. Detta eftersom Entity Framework, enligt mig, blir svårare att kombinera med dagens diagnosprogram. Med svårare menar jag att det kommer att krävas mer omstrukturering och omprogrammering av diagnosprogrammet än det kommer bli om man använder det dataåtkomstlager som finns idag, nämligen nuvarande resurslager. Prototypen är gjord i .NET med C#, WPF och WCF tillsammans med distribueringstekniken Click-Once. Prototypen består av två delar, en serverdel och en klientdel. Serverdelen exponerar ut de metoderna i resurslagret som diagnosprogrammet använder sig av, i form av webbtjänster. Klientdelen kommer att konsumera dessa webbtjänster och på ett lämpligt sätt visa att man kan ta emot en godtycklig datastruktur från resurslagret. Tester görs också för att avgöra hur bra arkitekturen med webbtjänster står sig emot referensarkitekturen i kapitel fyra, det vill säga arkitekturen som ansluter sig direkt till Microsoft SQL Server. En bild på hur den logiska arkitekturen som prototypen baserar sig på kan ses i figur 6.1.
PROTOTYP
44
Figur 6.1. Bild på hur den logiska modellen av prototypen ser ut.
6.2 Implementation av prototyp
Prototypen av klienten efterliknar uppkopplingsscenariot. Klienten måste autentisera sig innan den får tillgång till webbtjänsterna. Flera klienter ska också samtidigt kunna ansluta till servern. Jag valde att lösa problemet med att datatyperna som returneras innehåller metoder (finns beskrivet i avsnitt 5.3) genom att lyfta ut dessa och istället göra de tillgängliga via klienten. För att få dessa datatyper att serialiseras med WCF var jag tvungen att lägga till annoteringar i form av "[DataContract]" och "[DataMember]". En webbtjänstreferens för att hämta bilder från servern finns också tillgänglig. Figur 6.2 visar prototypen som utvecklades. Bilden visar hur man genom programmet kan hämta en godtycklig datastruktur från databaserna (som ligger på en annan dator) med WCF, det vill säga via webbtjänster. Av sekretesskäl har jag inte bifogat någon kod i rapporten, men man kan se hur konfigurationsfilen för WCF ser ut, med hänsyn till prototypen, i bilaga 2.
PROTOTYP
45
Figur 6.2. Prototypen som använder sig av WCF.
Webbtjänsten var, under tiden som fanns, optimerad så gott det går, där det med den absolut första lösningen som användes tog över 30 sekunder för en klient att efterlikna uppkopplingsscenariot. Denna tid lyckades jag få ner till 7.5 sekunder. Optimeringarna bestod av punkterna nedan:
Göra så att samtliga webbtjänstanrop använder sig av samma instans av resurslagret. Det vill säga att skapa en statisk instans av resurslagret.
Se till att varje anrop till webbtjänsterna får sin egen "SqlConnection-instans".
Göra det nuvarande resurslagret trådsäkert samt se till att bara operationer som är nödvändiga utförs i alla givna tidpunkter.
Tillåta flera trådar (klienter) att använda webbtjänsten samtidigt, istället för att använda det förinställda värdet som är att bara en klient tillåts använda tjänsten åt gången.
6.3 Test av prototyp
För att jämföra hur bra denna lösning var, jämfört med referenslösningen beskriven i kapitel fyra, så gjordes ett antal prestandatester. Testförutsättningarna var exakt likadana som för referenslösningen, samma datorer användes som klient respektive server och samma demofil användes för att efterlikna uppkopplingsscenariot, det vill säga:
PROTOTYP
46
Testuppsättning Klient(er) Dator: Intel Xeon, W3520 @ 2.67GHz, 3.50GB Ram. Anslutningen var lokalt nätverk 100Mbit. Server (ej samma dator som klienten) Dator: Intel Xeon, W3520 @ 2.67GHz, 3.50GB Ram. Anslutningen var lokalt nätverk 100Mbit. Webbtjänsten placerades på en webbserver som körde Microsoft IIS (Internet Information Services). I figur 6.3 nedan ses en tidsutvecklingsgraf över hur tiden ökar med antalet klienter som gör en uppkoppling mot en server samtidigt. Medeltider för hur en klient beter sig mot en webbserver belägen på intranätet som är belastad med ett antal andra klienter ses nedan. För att få en uppskattning av hur lång tid som en klient tar på sig när servern är belastad med ett antal andra klienter, så har alla klienter startats samtidigt och därifrån en medeltid över samtliga tagits. Medeltid för klient(er) mot en server över intranätet med WCF: 1 klient mot en server: 7.5s 5 klienter mot en server: 9.5s 10 klienter mot en server: 14s 25 klienter mot en server: 28s 50 klienter mot en server: 60s 100 klienter mot en server: 90s Tidsutvecklingsgraf:
Figur 6.3. En graf över hur tiden ökar med antalet klienter som kör uppkopplingsscenariot med webbtjänster mot enbart en extern webbserver. Genom ovanstående resultat kan man se att tiden det tar att efterlikna uppkopplingsscenariot med enbart en klient är ungefär tre sekunder långsammare med webbtjänster än om man skulle anslutit direkt till Microsoft SQL Server som i referenslösningen beskriven i kapitel fyra (7.5 sekunder mot 4.3 sekunder).
0
10
20
30
40
50
60
70
80
90
100
1 klient 20 klienter 40 klienter 60 klienter 80 klienter 100 klienter
S
e
k
u
n
d
e
r
Tidsgraf
PROTOTYP
47
Mängd data En uppskattning av hur stor mängd data som skickas mellan en klient och en server under ett uppkopplingsscenario gjordes med två olika demofiler, en med ett litet antal styrenheter och en som innehöll ett stort antal styrenheter. Detta för att få två extremvärden både uppåt och neråt datamängdsmässigt. Mätprogrammet som användes var ”DU Meter”. Med programmet kan man enkelt vid en given tidpunkt mäta datamängden som ett program producerar. Resultatet blev att man i genomsnitt kan förvänta sig att ungefär 15MB data kommer att passera över nätverket under en uppkoppling.
ANALYS
48
Kapitel 7
Analys Det här kapitlet reflekterar och analyserar de resultat som undersökningarna av arkitekturerna har kommit fram till. En analys av hur man kan kombinera arkitekturen på smidigast möjliga sätt med dagens diagnosprogram, och därmed få en slags "klient", utförs också.
7.1 Referenslösningen och webbtjänstarkitekturen
7.1.1 Programmet som efterliknar uppkopplingsscenariot
Eftersom man på ett någorlunda riktigt sätt ville kunna jämföra de olika lösningarna som arbetet har utmynnat i, så användes ett program som efterliknar ett uppkopplingsscenario i det riktiga diagnosprogrammet. En bild på programmet ses i figur 7.1 och programmet beskrivs mer ingående i kapitel fyra.
Figur 7.1. Programmet som testar databasernas prestanda.
Eftersom programmet bara efterliknar databasinteraktionen under en uppkoppling, finns det vissa brister. Dessa brister handlar mest om att man skulle vilja implementera uppkopplingsscenariot i sin helhet, så som det ser ut i dagens diagnosprogram, eftersom man då skulle få mer koll på exakt hur mycket uppkopplingstiden försämras med hänsyn till alla faktorer. Affärskomponenterna kommer att efterfråga data från databaserna mer sporadiskt än mitt testprogram gör och därför kan man få helt andra uppkopplingsbeteenden, bättre eller sämre, med de prestandatester som jag har utfört. Anledningen till att jag inte implementerat hela uppkopplingsscenariot, eller för den delen använt diagnosprogrammets kodbas för mina tester, har varit att komplexiteten att arbeta med ett så stort program som diagnosprogrammet skulle blivit för tidskrävande. Det finns två skäl till detta: tiden fanns inte att sätta sig in i de delar som krävdes och att buggrättningen skulle blivit mycket svårare. Dock ger mitt testprogram ett någorlunda rättvisande resultat eftersom alla tester har utförts med samma villkor och det var interaktionstiden med databaserna som undersökningarna var ute efter.
7.1.2 Referenslösningen
Referenslösningarna som arbetet berört är dels hur snabbt uppkopplingsscenariot går med dagens Microsoft Access databaser samt dels hur snabbt det går om man använder
ANALYS
49
Microsoft SQL Server som databashanterare istället. Resultaten från dessa undersökningar kan ses i figur 7.2 och figur 7.3. Mer utförlig information återfinns i kapitel fyra.
Figur 7.2. Medeltider för de olika testfallen i sekunder. Benämning SQL betyder att mätningen skett mot Microsoft SQL Server. De två första staplarna är mätningar gjorda mot den lokala datorn medan de resterande är gjorda mot en Microsoft SQL Server belägen på en annan dator.
Figur 7.3. Graf över hur tiden ökar med antalet klienter som kör uppkopplingsscenariot mot enbart en server körandes databashanteraren "Microsoft SQL Server".
Det första som är intressant att ta med sig från dessa resultat är att Microsoft SQL Server utför uppkopplingsscenariot ungefär två sekunder snabbare än Microsoft Access gör (som dagens diagnosprogram använder sig av). Det andra är att tidsgrafen som ses i figur 7.3 visar vad man kan förvänta sig för prestanda som bäst tidsmässigt, för en klient som utför en uppkoppling, när antalet klienter stiger. Tittar man på tidsgrafen kan man se ungefär var någonstans belastningen av klienter som utför uppkopplingsscenariot blir för många för att det ska flyta tidsmässigt hos varje klient. En uppkoppling ska enligt uppgifter idag ta i genomsnitt 40 sekunder, detta inkluderar uppläsning av data från fordonets styrenheter, uppläsningen av data från databaserna samt intern bearbetning hos affärskomponenterna. Då innebär det att uppläsningen från databaserna på sin höjd inte får överstiga 40 sekunder det vill säga att det max får vara runt 70 klienter anslutna samtidigt (till en server) som utför uppkopplingsscenariot. I ett sådant här fall skulle man vilja använda diagnosprogrammet och utföra en riktig uppkoppling för att avgöra hur mycket tiden det tar att läsa data från databaserna kan försämras innan hela uppkopplingstiden försämras. Resultaten med flera klienter ska tas med en nypa salt eftersom att alla klienter kördes på samma dator vilket är
0
1
2
3
4
5
6
7
8
Access (lokal maskin)
SQL (lokal maskin)
SQL (1 klient) SQL (2 klienter)
SQL (3 klienter)
SQL (6 klienter)
SQL (10 klienter)
S
e
k
u
n
d
e
r
Medeltider
0
10
20
30
40
50
60
70
80
1 klient 20 klienter 40 klienter 60 klienter 80 klienter 100 klienter
S
e
k
u
n
d
e
r
Tidsgraf
ANALYS
50
overkligt i ett riktigt scenario. Eftersom alla klienter körs på samma dator kommer kapaciteten beräkningsmässigt hos datorn att vara begränsande och ge missvisande resultat men då åt det negativa hållet (det vill säga det tar längre tiden än det egentligen ska ta).
7.1.3 Webbtjänstarkitekturen
Jag valde att undersöka en arkitektur där man använder sig av webbtjänster för att exponera ut metoder som ger åtkomst till databaserna. Anledningarna till att jag valde att undersöka detta istället för att bara använda mig av referenslösningen och exponera ut Microsoft SQL Server på en server direkt var:
Man ska aldrig i professionella sammanhang exponera ut en databasserver direkt över Internet. Det vill säga att man aldrig vill exponera det oftast mest värdefulla i sitt program, nämligen databasinformationen, och riskera att få denna korrupt.
Det man vill exponera mot omvärlden är istället webbtjänster med fördefinierad funktionalitet.
Man vill inte skicka SQL-satser mellan klient och server och riskera att exponera databasstrukturen utan man vill skicka objekt som är oberoende av strukturen.
Ett mellanlager krävs för att utnyttja en tre-nivåers arkitektur och därmed åstadkomma högre skalbarhet samt att minska risken att systemet hamnar i konceptet "single-point-of-failure".
Den arkitektur som jag till slut valde att implementera en prototyp av samt utföra prestandatester på, kan ses i figur 7.4. Figur 7.4. En bild på hur den logiska modellen av prototypen ser ut.
ANALYS
51
Prototypen består av att exponering av resurslagrets metoder via webbtjänster görs till klienten. Anledningen till att jag valde att använda mig av de tekniker som prototypen bygger på är att de alla har en sak gemensamt: de förenklar återanvändning av diagnosprogrammets kod. De prestandatester som utfördes mot referenslösningen utfördes också mot prototypen. Resultatet kan ses i figur 7.5.
Figur 7.5. Graf över hur tiden ökar med antalet klienter som kör uppkopplingsscenariot med webbtjänster mot enbart en extern webbserver.
Det som är intressant här är att tidsresultaten inte är drastiskt mycket sämre än för referenslösningen utan kurvan verkar till och med "plana" ut sig. Eftersom en uppkoppling enligt uppgifter idag tar i genomsnitt 40 sekunder kan man se att det på sin höjd kan vara ungefär 35 klienter anslutna till samma server. I ett sådant här fall så skulle man vilja använda diagnosprogrammet och utföra en riktig uppkoppling för att avgöra hur mycket tiden det tar att läsa data från databaserna, kan försämras, innan hela uppkopplingstiden försämras. Resultaten med flera klienter ska tas med en nypa salt eftersom att alla klienter kördes på samma dator vilket är overkligt i ett riktigt scenario. Eftersom alla klienter körs på samma dator så kommer kapaciteten beräkningsmässigt hos datorn att vara begränsande och ge missvisande resultat men då åt det negativa hållet (det vill säga det tar längre tiden än det egentligen ska ta). Uppkopplingsscenariot som efterliknas utför också ett genomsnitt av 1000 anrop till dessa webbtjänster, vilket tar tid och skulle kunna förbättras genom att "klumpa ihop" anropen till webbtjänsten. Problemet med att "klumpa ihop" anropen är att det kommer krävs omstrukturering och omprogrammering av dagens diagnosprograms affärslager om man väljer att implementera detta och därför har jag istället valt att undersöka prestandan utan "klumpning".
7.1.4 En datamängds- och skalbarhetsanalys
Mätningar av hur mycket data som skickas mellan en server och en klient har gjorts för både referenslösningen och webbtjänstlösningen. Resultatet var 5MB för referenslösningen och 15MB för webbtjänstlösningen. Hur mycket data som skickas över nätverket är viktigt att veta i ett onlinebaserat scenario då begränsningar förekommer. Dessa begränsningar yttrar sig mest i hur snabb uppkoppling klienten har. Ett enkelt exempel kan vara om klienten har en uppkoppling som har kapacitet att leverera 1 MB/s, då kommer det att ta (i genomsnitt med referenslösningen) minst 5MB/1MB sekunder, det vill säga fem sekunder, att hämta data från databasen. Om klientens uppkopplingsbandbredd skulle vara ännu lägre, så skulle tiden det tar för Microsoft SQL Server att processera databasärendena (för en klient, det vill
0
10
20
30
40
50
60
70
80
90
100
1 klient 20 klienter 40 klienter 60 klienter 80 klienter 100 klienter
S
e
k
u
n
d
e
r
Tidsgraf
ANALYS
52
säga 4.3 sekunder) inte längre vara flaskhalsen utan snarare tiden det tar att föra databasinformationen över Internet. Även hur snabb uppkopplingen databasservern har måste man ta hänsyn till, då man kan förvänta sig att ett flertal användare kommer vara anslutna och hämta data från databaserna samtidigt. Jämför man datamängden för webbtjänstlösningen (15MB) med den mängd som referenslösningen utmynnade i (5MB) ser man att det blir ett extra datapålägg på ungefär 10MB. Detta pålägg beror på att XML-serialiseringen av de databasobjekt som skapas av resurslagret lägger till en massa annoteringar kring det data som skickas för att kunna skapa upp samma databasobjekt på andra sidan (hos klienten). Tittar man på denna datamängd kommer en klient med en uppkoppling på 1MB/s att behöva minst i genomsnitt (15MB/1MB) = 15 sekunder på sig för att ladda ner all data från servern. I och med att datamängden för webbtjänstlösningen är i genomsnitt 15MB per uppkoppling så talar detta för att man skulle behöva använda sig av någon slags dynamisk hämtning av data från webbservern, och alltså inte läsa upp alla data direkt vid uppkoppling, om man inte vill offra tiden det tar att koppla upp sig mot ett fordon. Man skulle också kunna försöka få ner datamängden som skapas av XML-serialiseringen genom att använda sig av någon annan slags serialisering. För att kunna utföra avgörande analyser om skalbarheten måste två frågor besvaras:
Hur snabb uppkoppling har en klient på verkstaden tillgång till?
Hur många klienter kan tänkas ansluta samtidigt till den centrala serverstacken som skapas?
Dessa två frågor kan verka enkla att besvara men faktum är det inte finns någon riktigt information om detta. Dock ska det i framtiden genom implementation av så kallad "uppskickning av driftdata" kunna gå att ta reda på hur stort klienttryck det kan tänkas vara. Eftersom arbetet inte har svaret på frågan om hur många klienter som kan tänkas ansluta till den centrala serverstacken kan bara antaganden göras. Anta att det är 100 användare av diagnosprogrammet som samtidigt kommer ansluta till en och samma servercentral hos Scania och att man inte använder någon dynamisk upphämtning av data. Låt oss också anta att var och en av dessa användare har en uppkoppling på 1MB/s, då kommer servercentralen att behöva en 100*1MB/s uppkoppling det vill säga 100MB/s. Vill man att det ska flyta på kommer man behöva minst 3 stycken databasservrar att distribuera trafiken över, detta eftersom min prototyp inte klarar mer än 35 anslutningar per server innan tiden att läsa all data går över 40 sekunder på en server. Med dessa antaganden ovan skulle man i teorin kunna förvänta sig att ingen användare av diagnosprogrammet skulle behöva vänta mer än 40 sekunder för att få sitt data i uppkopplingsscenariot. Jag tror inte att skalbarheten är något problem i och med att man kan lösa det med att distribuera trafiken över flera servrar med så kallad lastbalansering. Generellt, som även finns beskrivet innan, så måste man göra en avvägning där man kommer fram till hur mycket databasernas prestanda vid en uppkoppling kan försämras innan det påverkar hela tidsresultat. En riktig undersökning där man utför en uppkoppling mot en central server
ANALYS
53
placerad på Scania från en verkstad måste också utföras. Dessa centralservrar kommer att ha mycket högre prestanda än de datorer som jag har testat med och därför skala bättre.
7.2 En diagnosprogramsklient
7.2.1 Kombinera arkitekturen med dagens diagnosprogram
Min arkitektur bygger på man ska dela upp dagens diagnosprogram i två delar, där den ena delen är databaserna och den andra delen resterande diagnosprogram. Eftersom arkitekturen använder sig av nuvarande resurslager för att exponera databaserna är det inte mycket som behöver ändras i diagnosprogrammet för att stödja detta. Det som behöver ändras är att man, istället för använda resurslagret som kopplar upp sig mot Microsoft Access databaser, skapar ett resurslager som konsumerar de webbtjänster som min arkitektur exponerar. För att sedan autentisera sig mot webbtjänsterna kan man använda sig av den mjukvarunyckel som Scania håller på att utveckla. Eftersom webbtjänsttekniken WCF används kan man också i framtiden flytta upp ytterligare funktionalitet från klienten till servern. Den resterande delen av diagnosprogrammet distribueras med tekniken Click-Once för att uppfylla kraven på automatisk uppdatering, enkel hämtning och enkel installation. Distribuera med Click-Once Som beskrivet i teoridelen, avsnitt 2.3.3, så måste man antingen certifiera eller låta användaren självmant utöka förtroendet om man vill undkomma de begränsningar som Click-Once sätter när man hämtar en applikation från Internet. Väljer man att inte certifiera sin applikation, vilket gör att klienten inte behöver göra något extra för att köra programmet, så måste man vara noga med att explicit sätta vad programmet kräver säkerhetsmässigt. Gör man inte detta kan klienten i värsta fall krascha om man inte varit noga med att ta emot de undantag som kastas i dessa scenarion. Fördelen med att låta databaserna ligga på en extern server är att resterande diagnosprogram inte blir mer än cirka 114MB stort, vilket med en godtycklig uppkoppling i dagens läge inte borde ta allt för lång tid att ladda ner. Diagnosprogrammet använder sig även av externa DLL:er vilket är helt kompatibelt med Click-Once. Det går inte att modifiera hur installationsprogrammet för Click-Once beter sig eller var installationen placeras, dock ser jag ingen anledning till att man skulle behöva ändra på detta heller. Vill man få ner storleken av diagnosprogrammet ytterligare skulle man kunna hämta de externa DLL:erna för språket dynamiskt och kanske till en början enbart hämta ett standardspråk, till exempel engelska.
7.2.2 Analys om en framtida tunn klient
I förlängningen om man väljer att utveckla diagnosprogrammet som en riktigt tunn klient skulle jag rekommendera att man använder Entity Framework, Silverlight samt WCF RIA Services. Det är även den teknologistack som Microsoft rekommenderar samt har utvecklat för att skapa webblösningar med flera lager. Med dagens lösning är det enklast och vettigast att använda sig av Click-Once om man vill ha ett diagnosprogram som hos klienten är enkelt att installera samt uppdaterar sig själv automatiskt. Ett första steg mot en tunn klient är att separera databaserna från diagnosprogrammet med en teknik som möjliggör ytterligare uppflyttningar av diagnosprograms funktionalitet. Detta är fördelaktigt i och med att det
ANALYS
54
bara är 5MB av data som läses vid en genomsnittlig uppkoppling mot de närmare 229 MB stora databaserna. Eftersom det ställs stora krav på realtidskommunikation måste interaktionen mellan lastbil, klient och server gå smärtfritt. Detta gör att den del av diagnosprogrammet som kommunicerar med lastbilen måste ligga hos klienten. Eftersom diagnosprogrammet består, i mångt och mycket, av kommunikation med lastbilen får en avvägning göras hur mycket av funktionaliteten som man är villig att flytta upp från klienten till servern. Det kan hända att mycket av den kommunikation med lastbilen man gör består av uppkopplingsscenariot och det därför kanske inte krävs någon större kommunikation i resterande användning av programmet, och det därför går att lägga mycket av funktionaliteten på servern. Det finns dock sådant som måste ligga på klienten, till exempel om man vill visa en realtidsgraf över värmen i motorn. Då måste funktionaliteten att bearbeta och visa motorvärmen finnas hos klienten. Ett exempel där man kan diskutera om man vill lägga funktionaliteten på servern eller klienten är när man ritar upp kretsdiagram utifrån data, vilket vad jag har förstått är ett mycket krävande moment. Överlag kan man, med hjälp av hur arkitekturen ser ut idag, skissa på hur man skulle kunna tänkas dela upp funktionaliteten i olika moduler där varje sådan på ett godtyckligt sätt kan kommunicera med en annan. På så sätt är man inte beroende av att hela diagnosprogrammet ligger på samma dator.
7.3 Den fysiska arkitekturen
Arbetet har utmynnat i en fysisk arkitektur som kan ses i figur 7.6.
Figur 7.6. Den fysiska arkitektur som arbetet utmynnat i. Med min prototyp innebär det att man placerar Microsoft SQL Server i det interna nätverket och webbservern med webbtjänsterna i den demilitariserade zonen. Fördelen med detta är
ANALYS
55
att den demilitariserade zonen har kontakt med både det interna nätverket samt Internet medan anslutningar som kommer från Internet bara har kontakt med den demilitariserade zonen. Det vill säga att det enbart kommer vara webbservern i den demilitariserade zonen som kommer vara utsatt för attacker medan den riktiga databasservern håller sig oskadd i det interna nätverket. Rent konfigurationsmässigt löser man uppdelningen av zonerna med olika subnät. Installationen till diagnosprogrammet skulle också ligga i den demilitariserade zonen och använda sig av tekniken Click-Once samt enbart vara tillgänglig via någon form av autentisering. För att kommunicera med webbtjänsterna i den demilitariserade zonen måste man autentisera sig och där skulle man i framtiden kunna använda sig av den mjukvarunyckel som Scania håller på att utveckla. Kommunikationen mellan webbtjänsterna och klienterna är krypterad med tekniken SSL för att försvåra intrång utifrån.
SLUTSATSER
56
Kapitel 8
Resultat, slutsatser och sammanfattning Kapitlet ger en kort sammanfattning av vad som undersökts i rapporten. Slutsatser och resultat återfinns också.
8.1 Vad har rapporten berört?
Arbetets syfte har varit att ta upp och belysa frågor som är viktiga i ett framtida arbete med ett onlinebaserat diagnosprogram. Dessa viktiga frågor listas i punktform nedan:
Hur ska man dela upp arkitekturen i dagens diagnosprogram för att stödja en klient/server-arkitektur?
Hur tunn kan klienten vara med hänsyn till de krav som ställs på dagens diagnosprogram (kraven listas i kapitel fyra)?
Hur ska man realisera de krav som ställs på ett Scania Diagnos för att på bästa sätt uppfylla dessa?
Vilka tekniker passar sig för denna typ av problem?
Hur åstadkommer man en säker kommunikation mellan server och klient?
Går det att återanvända den kod som idag finns skriven och därmed skynda på övergångsprocessen till ett onlinebaserat diagnosprogram?
Hur ska man göra för att diagnosprogrammet ska hålla sig uppdaterat?
Den onlinebaserade lösningen ska gå att distribuera som en "stand-alone"-lösning, för att felsökningar utan tillgång till Internet ska gå att genomföra.
Huvudsyftet för Scania har varit att få ett diagnosprogram som uppfyller kraven på automatisk uppdatering, enkel hämtning och enkel installation. I denna rapport kan man läsa om hur dagens diagnos program fungerar, vilka tekniker som är lämpliga för ett onlinebaserat diagnosprogram samt den klient/server-arkitektur som jag kommit fram till. Den framkomna arkitekturen har också prestandatestats och därmed jämförts med dagens diagnosprogram samt analyserats ur både skalbarhets- och datamängdssyfte.
8.2 Teknikvalen
De tekniker som undersöks i rapportens teoridel är Silverlight, WPF XBAP, Click-Once, NHibernate, Entity Framework, WCF and WCF RIA Services. Slutsatserna kring teknikvalen är som följer:
För klienten (presentationsnivån): Valet blev att använda sig av distributionsmodellen "Click-Once" eftersom det uppfyller de flesta av de krav som Scania har. Det uppfyller kraven på återanvändning av kod, möjlighet att till stora delar obehindrat interagera med datorn säkerhetsmässigt samt på ett smidigt sätt kunna hålla programmet uppdaterat. Jag rekommenderar inte Silverlight då det (i dagens läge) har för stora
SLUTSATSER
57
begränsningar för att på ett smidigt sätt kunna återanvända kod samt uppfylla säkerhetsmässiga krav. Teknikgenomgången återfinns i avsnitt 2.4.
För kommunikationen mellan klient och server: WCF istället för WCF RIA Services då de senare är utvecklat för Silverlight och inte för resterande .NET-tekniker.
För servern (applikations- och databasnivån): Rekommendationen är att använda sig av nuvarande resurslager för att uppfylla kraven på en sömlös och snabb övergång samt återanvändning av kod. I framtiden kan man dock fundera på att använda sig av det andra alternativet jag studerade nämligen Entity Framework då det lämpar sig för onlinebaserade lösningar.
8.3 Arkitekturen
8.3.1 Uppdelning av dagens diagnosprogram
Eftersom diagnosprogrammet är ett stort program med många krav, bland annat på realtidskommunikation med fordon vid felsökning, valde jag att inte ge mig in i hur en tänkbar uppdelning av affärslogiken med mera skulle se ut. Jag valde istället att titta på hur en onlinebaserade arkitektur med databaserna, som i dagens läge följer med installationen av diagnosprogrammet som "Microsoft Access"-databaser, på en extern server skulle kunna se ut. Det fanns framförallt två huvudsyften med detta:
Databaserna i dagens diagnosprogram utgör cirka 230MB utav det totala 340MB.
Uppfylla kravet på att man ska kunna uppdatera databaserna utan att klienten ska behöva uppdatera sin programvara.
Det resterande diagnosprogrammet skulle då finnas tillgängligt via Internet som en "Click-Once"-installation. För att göra den arkitektur säker valde jag att studera den logiska arkitekturkartan som ses i figur 8.1.
SLUTSATSER
58
Figur 8.1. Arkitektur med antingen Entity Framework eller nuvarande resurslager. WCF används som webbtjänstteknik mellan klienten och servern och exponerar metoder till något av dataåtkomstlagren. Syftet med att exponera ut webbtjänster istället för att exponera ut databasservern direkt är:
Man ska aldrig i professionella sammanhang exponera ut en databasserver direkt över Internet. Det vill säga att man aldrig vill exponera det oftast mest värdefulla i sitt program, nämligen databasinformationen, och riskera att få denna korrupt.
Det man vill exponera mot omvärlden är istället webbtjänster med fördefinierad funktionalitet.
Man vill inte skicka SQL-satser mellan klient och server och riskera att exponera databasstrukturen utan man vill skicka objekt som är oberoende av strukturen.
Ett mellanlager krävs för att utnyttja en tre-nivåers arkitektur och därmed åstadkomma högre skalbarhet samt att minska risken att systemet hamnar i konceptet "single-point-of-failure".
Jag studerade vilken av de två dataåtkomstteknikerna, Entity Framework eller nuvarande resurslager, som man skulle exponera via webbtjänsterna och slutsatsen var att med de krav på återanvändning av kod som Scania har att det var rimligast att använda sig av det nuvarande resurslagret. Det första som implementerades i den logiska arkitekturen var att byta ut databashanteraren Microsoft Access mot Microsoft SQL Server och på det utföra ett antal prestandatester samt datamängds- och skalbarhetsanalyser. Efter det utvecklades en prototyp som implementerade den logiska arkitekturen som det också gjordes ett antal prestandatester samt datamängds- och skalbarhetsanalyser på. Vad dessa prestandatester
SLUTSATSER
59
baserade sig på kan ses i kapitel fyra men enkelt kan man säga att dessa tester försökte efterlikna ett riktigt uppkopplingsscenario mot ett fordon. Från dessa resultat jämfördes hur min onlinebaserade arkitektur stod sig emot dagens diagnosprograms arkitektur. Resultatet från testerna ses nedan i figur 8.2 och i figur 8.3.
Figur 8.2. Graf över hur tiden ökar med antalet klienter som kör uppkopplingsscenariot mot enbart en server körandes databashanteraren Microsoft SQL Server.
Figur 8.3. Graf över hur tiden ökar med antalet klienter som kör uppkopplingsscenariot med webbtjänster mot enbart en extern webbserver.
Hur stor mängd data som skickades över nätverket analyserades och resulterade i att det med anslutningen direkt mot databashanteraren Microsoft SQL Server krävdes 5MB och att det mot webbtjänsterna krävdes 15MB. I rapporten har jag dragit slutsatsen att den datamängd, 15MB, som förs över nätverket förmodligen kommer kräva någon slags dynamisk upphämtning av data för att klienten inte ska bli alltför beroende av den centrala serverstackens uppkopplingshastighet. Slutsatsen om hur bra min webbtjänstbaserade arkitektur står sig mot arkitekturen hos dagens diagnosprogram var att en viss försämring sker rent prestandamässigt men att många optimeringar kan göras för att förbättra prestandan (finns beskrivna i avsnitt 9.1, framtida rekommendationer).
0
10
20
30
40
50
60
70
80
1 klient 20 klienter 40 klienter 60 klienter 80 klienter 100 klienter
S
e
k
u
n
d
e
r
Tidsgraf (SQL)
0
10
20
30
40
50
60
70
80
90
100
1 klient 20 klienter 40 klienter 60 klienter 80 klienter 100 klienter
S
e
k
u
n
d
e
r
Tidsgraf (webbtjänst)
SLUTSATSER
60
Slutsatsen från mätningarna av den webbtjänstbaserade arkitekturen var att en avgörande analys kring hur bra detta står sig i verkligheten inte kunde utföras då tre huvudfrågor inte kunde besvaras (dock finns det en antagande analys i kapitel sju):
Hur snabb uppkoppling har en klient på verkstaden tillgång till?
Hur många klienter kan tänkas ansluta samtidigt till den centrala serverstacken som skapas?
Hur mycket kan uppläsningstiden från databaserna försämras innan hela uppkopplingsscenariot försämras?
8.3.2 Den fysiska arkitekturen
Den fysiska arkitekturen som arbetet utmynnat i kan ses i figur 8.4.
Figur 8.4. Den fysiska arkitektur som arbetet utmynnat i.
För att kommunicera med webbtjänsterna i den demilitariserade zonen måste man autentisera sig och där skulle man i framtiden kunna använda sig av den mjukvarunyckel som Scania håller på att utveckla. Kommunikationen mellan webbtjänsterna och klienterna är krypterad med tekniken SSL för att försvåra intrång utifrån. Slutsatsen är att den här lösningen är rimlig att använda i framtiden och uppfyller de kriterium som teoridelen ställer när man bygger N-nivåer applikationer. Det vill säga att man ska använda sig av tre eller fler nivåer för att uppfylla kraven på skalbarhet och enkel underhållning. Klienten i det här fallet är utvecklad som en fet klient och uppfyller därmed per definition kraven som finns på dagens diagnosprogram (kravlista i avsnitt 4.1). De krav som ställs specifikt för den onlinebaserade lösningen i avsnitt 4.1 är:
Säkerhet över Internet (använda en mjukvarunyckel istället för en hårdvarunyckel).
SLUTSATSER
61
Servern och databasen måste vara multitrådad och kunna hantera flera anslutningar samtidigt.
Skalbarhet och prestanda, det vill säga att det kanske inte är möjligt att läsa upp samtlig information i databasen direkt (som man gör i dagens lösning) utan man får läsa efterhand som det behövs.
Referera till databasbilder samt andra resurser genom servern.
Klienten har tillgång till ett gränssnitt med WCF istället för nuvarande resursgränssnitt.
Krav på realtidskommunikation mellan server, klient och fordon.
Möjlighet att uppgradera klientens programvara på avstånd.
Uppdatera databaserna utan att klienterna ska behöva uppdateras.
Återanvändning av kod.
Den onlinebaserade lösningen ska gå att distribuera som en "stand-alone"-lösning, för att felsökningar utan tillgång till Internet ska gå att genomföra.
Alla dessa krav uppfylls (mer eller mindre) med den lösningsarkitektur som arbetet utmynnat i. Slutsatsen kring hur man ska göra för att uppfylla kraven på automatiskt uppdatering, enkel hämtning och enkel installation är att man ska använda sig av distribueringstekniken Click-Once till att börja med, för att senare i en tunnare klient kanske fundera på Silverlight. Arbetet har inte berört i detalj hur väl dagens diagnosprogram, utan modifikation, kan använda sig av Click-Once men antaganden har gjorts att det inte ska finns några oöverkomliga problem. För att kommunicera med webbtjänsterna i den demilitariserade zonen måste man autentisera sig och där skulle man i framtiden kunna använda sig av den mjukvarunyckel som Scania håller på att utveckla. Kommunikationen mellan webbtjänsterna och klienterna är krypterad med tekniken SSL för att försvåra intrång utifrån. Slutsatsen om hur arkitekturen kan användas i framtiden är att teknikerna som används är helt kompatibla med en utveckling mot en tunn klient. Det vill säga att arkitekturen stödjer att man flyttar upp mer funktionalitet från klienten till servern. Kravet på återanvändning av kod uppfylls också med arkitekturen och kan utan alltför mycket arbete implementeras i det nuvarande diagnosprogrammet. Arkitekturen stödjer också att man från Scanias sida kan ändra i databaserna utan att ändra i klienterna.
8.4 Ett onlinebaserat Scania Diagnos möjligt?
Slutsatsen, om ett onlinebaserat Scania diagnos som uppfyller kraven på automatisk uppdatering, enkel hämtning och enkel installation kan realiseras, är ja. Den arkitektur som detta arbete har utmynnat i visar i högsta grad att det är en fullt fungerade första lösning i arbetet mot en framtida tunn klient. Målet med arbetet som var: "Målet är att forska fram en identifikation över utstående krav för just detta diagnosprogram och ge rekommendationer om vad man ska tänka på och hur man kan tänkas göra detta i framtiden om man väljer att gå över till en onlinebaserad lösning." blev helt klart uppfyllt.
SLUTSATSER
62
De fokuserade slutsatserna av arbetet är att man, till att börja med, ska använda sig av Click-Once tillsammans med en arkitektur där man har databaserna på en extern server, för att uppfylla kraven som ställs på diagnosprogrammet. Om en utveckling mot en framtida tunn klient påbörjas kan man med fördel fundera på, utöver Click-Once, om man kan tänkas använda sig av Silverlight, Entity Framework samt WCF RIA Services.
REKOMMENDATIONER
63
Kapitel 9
Framtida rekommendationer Rekommendationer för hur man ska gå vidare med arkitekturen som arbetet åstadkommit, i framtiden, återfinns i detta kapitel. Ett förslag på en alternativ onlinebaserad arkitektur finns också med.
9.1 Framtida arbete med arkitekturen
Det finns ett antal fortsatta rekommendationer för vidare arbete när det gäller att placera databaserna hos en central serverstack samt att göra en Click-Once installation av det resterande diagnosprogrammet, dessa är:
Undersöka hur skalbart detta är över Internet samt hur man ska få 100% tillgänglighet. Arbetet har inte haft tid att berör detta då komplexiteten kring att arbeta med en server utanför Scania har varit för stor.
Göra en mer grundläggande undersökning av hur man ska göra en ”Click-Once”-installation av det resterande diagnosprogrammet.
Optimera den lösningsarkitektur med nuvarande resurslager som detta arbete har utmynnat i. Till exempel genom att ”cacha” det data som bearbetas i SQL-servern så man snabbt kan hämta det nästa gång.
Undersöka hur man skulle kunna ”bunta” ihop webbtjänstanropen så dessa blir färre än de är i min lösningsprototyp. Antalet anrop där är ungefär 1000st i en genomsnittlig uppkoppling.
Studera hur man skulle kunna tänkas få ner det overhead på 10MB som blir om man använder WCF med XML-serialisering.
Ta reda på hur många klienter (användare av diagnosprogrammet) som (maximalt) samtidigt kan tänkas ansluta sig till den centrala serverstacken.
Hur snabb uppkoppling måste finnas hos klienterna för att det inte ska bli en flaskhals att hämta data? Här krävs det att man vet hur mycket databasuppläsningen kan försämras innan hela uppkopplingstiden försämras. Arbetet har inte berört detta då det blir för komplicerat att sätta sig in i och arbeta med det riktiga diagnosprogrammet.
Hur snabb uppkoppling måste finnas hos Scania för att leverera data tillräckligt fort till klienterna? Här måste frågan om hur många klienter som kan tänkas köra uppkopplingsscenariot samtidigt besvaras.
Hur ska ett lastbalanseringsscenario se ut?
9.2 Framtida arbete mot en tunn klient
Ett antal förslag på hur arbetet mot en tunn klient kan se ut är som följer:
Undersöka diagnosprogramsfunktionaliteten och avgöra vad som måste ligga på klienten och vad som kan placeras på servern.
Studera dagens arkitekturkarta över diagnosprogrammet och därifrån undersöka hur man skulle kunna dela upp arkitekturen med hänsyn till en tunn klient.
REKOMMENDATIONER
64
9.3 Ett annat förslag
En annan lösning man skulle kunna undersöka är att man, istället för att låta databaserna ligga centralt hos Scania, låter varje verkstad ha sin egen databasserver samt ”Click-Once”-server. På detta viset skulle Scania, till exempel på natten, kunna ha ett program som synkar alla dessa databas- och ”Click-Once”-servrar med de senaste utgåvorna och databaserna. På det sättet hålls databaserna samt klienterna uppdaterade i alla lägen.
LITTERATURLISTA
65
Litteraturlista
1. LHOTKA, R. 2008. Expert C# 2008 Business Objects. Apress, USA. ISBN: 978-1-4302-1019-1
2. WHITE PAPER THIN-CLIENT VS FAT-CLIENT COMPUTING, 2002, Frank McKenna, CEO
Knowledge one Corporation
3. Sommerville, I. 2007. Software Engineering – Eighth Edition. Pearson Education Limited, England. ISBN: 0321313798.
4. TROELSEN, A. 2007. Pro C# 2008 and the .NET 3.5 Platform, Fourth Edition. Apress.
ISBN: 978-1-59059-884-9
5. Berson, A. 1996. Client/Server Architecture – Second Edition. R. R. Donnelly & Sons Company, USA. ISBN: 0-07-005664-1.
6. MacDonald, M. 2010. Pro WPF in C# 2010. Apress. USA. ISBN: 978-1-4302-7205-2.
7. MacDonald, M. 2007. Pro ASP .NET 3.5 in C# 2008. Apress, USA. ISBN: 1-59059-893-
8.
8. Noyes, B. 2007. Smart Client Deployment with ClickOnce: Deploying Windows Forms Applications with ClickOnce. Addison-Wesley Professional, USA. ISBN: 978-0-321-19769-6.
Alla webbsidor senast besökta 2010-11-16.
9. Microsoft MSDN. Silverlight Application Security Model. 2010. http://msdn.microsoft.com/en-us/library/dd470128%28v=vs.95%29.aspx
10. Billy McCafferty. NHibernate Best Practices with ASP.NET. 2006. http://www.codeproject.com/KB/architecture/NHibernateBestPractices.aspx
11. Daniel Simmons. Building N-Tier Apps with Entity Framework 4. 2009.
http://msdn.microsoft.com/en-us/magazine/ee335715.aspx
12. Microsoft MSDN. Trusted applications. 2010. http://msdn.microsoft.com/en-us/library/ee721083%28VS.95%29.aspx
13. Microsoft MSDN. Silverlight Overview. 2010.
http://msdn.microsoft.com/en-us/library/bb404700%28v=VS.95%29.aspx
14. Brian Noyes. WCF RIA Services. 2010. http://www.silverlightshow.net/items/WCF-RIA-Services-Part-1-Getting-Started.aspx
LITTERATURLISTA
66
15. Microsoft MSDN. The ADO.NET Entity Framework Overview. 2010. http://msdn.microsoft.com/en-us/library/aa697427%28VS.80%29.aspx
16. SDP3 Manual. 2010.
17. SDP3 Arkitektur. 2010.
18. .NET Framework Conceptual Overview. 2010.
http://msdn.microsoft.com/sv-e/library/zw4w595w%28en-us%29.aspx
19. Understanding WCF Communication Options in the .NET Framework 3.5. 2010. http://msdn.microsoft.com/en-us/library/bb945107.aspx
BILAGOR
67
Bilagor Bilaga 1 Access (medeltid i sekunder – tid 1, tid 2, …): Lokal maskin (en instans): 4.6875s - 4.625s, 4.6875s, 4.71875s, 4.71875s, 4,645s
Microsoft SQL Server (medeltid i sekunder – tid 1, tid 2, …): Lokal maskin (en instans): 2.8875s - 2.890625s, 2.875s, 2.90625s, 2.875s, 2.890625s
En klient mot en server: 4.321875s - 4.28125, 4.328125, 4.4375, 4.3125, 4.25
4,55
4,6
4,65
4,7
4,75
1 2 3 4 5
2,85
2,86
2,87
2,88
2,89
2,9
2,91
1 2 3 4 5
4,15 4,2
4,25 4,3
4,35 4,4
4,45 4,5
1 2 3 4 5
BILAGOR
68
Två klienter mot en server: 4.44375s - 4.46875s, 4.484375s, 4.46875s, 4.28125s, 4.515625s
Tre klienter mot server: 4.7410670s - 5.03125s, 4.578125s, 4.5, 4.923009s, 4.6729514s
Sex klienter mot en server: 5.6973489s - 5.0941738s, 4.6722637s, 6.3599041s, 5.8442362s, 6.5161671s
Tio klienter mot en server: 6.9318266s - 7.7350185s, 7.6412607s, 6.6880564s, 8.1725549s, 4.4222429s
4,1
4,2
4,3
4,4
4,5
4,6
1 2 3 4 5
4,2
4,4
4,6
4,8
5
5,2
1 2 3 4 5
0
2
4
6
8
1 2 3 4 5
0
2
4
6
8
10
1 2 3 4 5
BILAGOR
69
Bilaga 2 Konfigurationsfilen web.config som prototypen använder sig av: <?xml version="1.0"?> <configuration> <system.web> <compilation debug="true" targetFramework="4.0" /> </system.web> <system.serviceModel> <bindings> <wsHttpBinding> <binding name ="test"> <security mode="TransportWithMessageCredential"> <message clientCredentialType="UserName"/> </security> </binding> </wsHttpBinding> </bindings> <behaviors> <serviceBehaviors> <behavior name="bs"> <!-- To avoid disclosing metadata information, set the value below to false and remove the metadata endpoint above before deployment --> <serviceMetadata httpGetEnabled="false" httpsGetEnabled="true"/> <!-- To receive exception details in faults for debugging purposes, set the value below to true. Set to false before deployment to avoid disclosing exception information --> <serviceDebug includeExceptionDetailInFaults="false"/> <serviceCredentials> <userNameAuthentication userNamePasswordValidationMode="Custom" customUserNamePasswordValidatorType="WcfService1.Validator, WcfService1"/> </serviceCredentials> </behavior> </serviceBehaviors> </behaviors> <serviceHostingEnvironment multipleSiteBindingsEnabled="true" /> <services> <service behaviorConfiguration="bs" name="WcfService1.Service1"> <endpoint bindingConfiguration="test" address="" binding="wsHttpBinding" contract="WcfService1.IService1" name="testservice"></endpoint> <endpoint address="mex" binding="mexHttpsBinding" contract="WcfService1.IService1" /> <host> <baseAddresses> <add baseAddress="https://jopeter-pc/Test"></add> <add baseAddress="https://jopeter-pc/Test" />
BILAGOR
70
</baseAddresses> </host> </service> </services> </system.serviceModel> <system.webServer> <modules runAllManagedModulesForAllRequests="true"/> </system.webServer> </configuration>
TRITA-CSC-E 2011:110 ISRN-KTH/CSC/E--11/110-SE
ISSN-1653-5715
www.kth.se
