Ökad tillgänglighet av existerande programvara genom ...

Examensarbete 

Ökad tillgänglighet av existerande 

programvara genom 

komponentifiering 

av 

Fredrik Jonsson 

LiTH-IDA-Ex-01/N 

2001-11-14 

Företag: GoldPen Computing AB 

Handledare på företaget: Fredrik Söderlund 

Examinator: Kristian Sandahl

SAMMANFATTNING 

Sammanfattning 

Komponentifiering av system betyder att man gör 

funktionalitet i detta tillgängligt för andra system. Detta gör 

systemen mer flexibla och interaktion mellan flera system 

lättare. Man kan exempelvis göra viss funktionalitet hos ett 

komplext system tillgängligt via ett webbgränssnitt. Det finns 

en mängd faktorer att ta hänsyn till när man vill utföra en 

komponentifiering, såsom tillgängliga tekniker för 

komponenten, den existerande programvarans uppbyggnad, 

programmeringsspråk, utvecklingsmiljö m.m. 

Tekniker som finns tillgängliga är exempelvis COM/DCOM, 

från Microsoft, men även CORBA, från The Object 

Management Group (OMG), och JavaRMI, från Sun 

Microsystems. För att exemplifiera komponentifieringen av 

ett existerande system implementerades ett exempelsystem 

med hjälp av COM. Denna komponent användes sedan via ett 

webbgränssnitt med hjälp av ASP, Active Server Pages, som 

exekverade på en Microsoft IIS webbserver. 

Utvecklingsmiljön för komponenten var Microsoft Visual 

C++, eftersom det existerande systemet är implementerat med 

hjälp av detta verktyg. Viktigt när det gäller 

komponentifiering är att man lätt ska kunna uppdatera sin 

komponent, den ska vara tillgänglig och effektiv, framför allt 

när det gäller minneshantering. Just minne kan vara svårt att 

hantera om komponenten ska användas via ett webbgränssnitt. 

För att välja teknik för komponenten bör man ta hänsyn till i 

vilken miljö komponenten ska exekvera, det existerande 

systemets implementationsspråk och framför allt hur 

komponenten ska användas. 

Förutom implementation av exempelsystemet med hjälp av 

COM har även DCOM studerats. Förslag på 

systemuppbyggnad med hjälp av den senare modellen har 

tagits fram. 

iii

iv 

Sammanfattning

Förord 

Förord 

Denna rapport är resultatet av ett examensarbete vid 

Institutionen för Datavetenskap (IDA) på Linköpings 

Tekniska Högskola (LiTH) under hösten 2001. Arbetet har 

utförts på uppdrag av GoldPen Computing AB i Linköping. 

Rapporten vänder sig till personer som vill lära sig mer om 

tekniker för komponentifiering, främst med hjälp av COM 

och DCOM, av existerande programvara. För att rapporten 

ska tillföra läsaren något bör denne besitta grundläggande 

kunskaper om datorer och programmering, framför allt 

Windows- och webbprogrammering. 

Linköping, 2002-03-28. 

Fredrik Jonsson 

v

vi 

Förord

Innehållsförteckning 


1 INTRODUKTION ......................................................................13 

1.1 BAKGRUND.....................................................................13 

1.2 SYFTE.............................................................................14 

1.3 LÄSANVISNINGAR ...........................................................14 

2 PROBLEMSPECIFICERING .......................................................17 

2.1 PROBLEMFORMULERING..................................................17 

2.2 MÅLBESKRIVNING...........................................................18 

3 FÖRSTUDIE .............................................................................21 

3.1 DET EXISTERANDE SYSTEMET..........................................21 

3.2 VAL AV UTVECKLINGSMILJÖ............................................23 

3.3 VAL AV KOMPONENTTEKNIK ...........................................23 

3.4 MICROSOFT VISUAL STUDIO............................................25 

3.5 COM/DCOM .................................................................25 

4 SAMMANFATTNING/SLUTSATSER AV FÖRSTUDIE ....................27 

4.1 UTVECKLINGSMILJÖ........................................................27 

4.2 KOMPONENTTEKNIK........................................................27 

4.3 UPPTÄCKTA PROBLEM UNDER FÖRSTUDIEN......................28 

4.4 SAMMANFATTNING .........................................................30 

5 PROTOTYPUTVECKLING.........................................................33 

5.1 WEBBGRÄNSSNITTET ......................................................33 

5.2 PROTOTYPERNA ..............................................................35 

5.3 JÄMFÖRELSE/UTVÄRDERING AV PROTOTYPERNA..............52 

6 IMPLEMENTATION AV EXEMPELSYSTEM ................................57 

6.1 ÖVERGRIPANDE ..............................................................57 

6.2 ARBETSGÅNG UNDER UTVECKLINGEN..............................58 

6.3 SYSTEMETS UPPBYGGNAD ...............................................59 

6.4 DESIGN...........................................................................59 

6.5 IMPLEMENTATION ...........................................................69 

6.6 RESULTAT AV DESIGN/IMPLEMENTATIONEN .....................73 

6.7 TESTNING .......................................................................73 

7 UTVÄRDERING OCH FÖRBÄTTRINGSFÖRSLAG ........................75 

vii

viii 


7.1 UTVÄRDERING................................................................75 

7.2 REAKTIONER FRÅN KUND OCH TESTPERSONER .................76 

7.3 FÖRBÄTTRINGSFÖRSLAG .................................................77 

7.4 ALTERNATIVA TEKNIKER (DCOM)..................................78 

8 SLUTSATSER, RESULTAT OCH ERFARENHETER.......................83 

8.1 SLUTSATSER/FÖRUTSÄTTNINGAR.....................................83 

8.2 RESULTAT.......................................................................84 

8.3 ERFARENHETER ..............................................................85 

9 BEGREPPSLISTA......................................................................87 

10 REFERENSER ..........................................................................91 

A. COM/DCOM.........................................................................95 

A.1 ALLMÄNT OM COM/DCOM ...........................................95 

A.2 ARKITEKTUREN HOS COM/DCOM .................................96 

A.3 GRÄNSSNITTET...............................................................97 

A.4 KLASSER/OBJEKT.......................................................... 102 

A.5 SÄKERHET.................................................................... 104 

A.6 PROCESS/TRÅDMODELL (THREADING MODEL)................ 106 

A.7 ARBETSFÖRDELNINGSMODELLER FÖR DCOM ............... 109 

A.8 MARSHALING ............................................................... 111 

B. MICROSOFT IIS OCH DCOMCNFG .................................... 115 

B.1 MICROSOFT IIS ............................................................ 115 

B.2 DCOMFNG................................................................. 116

1 Introduktion 

Introduktion 

Allteftersom Internet och WWW etablerat sig hos gemene 

man ökar efterfrågan av applikationer tillgängliga via detta 

forum. Man vill på företag kunna använda sina applikationer 

via exempelvis en webbläsare. Systemansvariga på företag 

inför restriktioner på vilken programvara som får installeras 

och användas i systemet. Lyckas man då konstruera 

programvara som kan köras genom exempelvis Internet 

Explorer, tjänar utvecklarna mycket pengar och tid eftersom 

de slipper genomgå certifieringsprocedurer på sina program, 

samt att man slipper installationsarbete på alla klienter som 

ska använda programvaran. Ännu bättre vore om man kunde 

slippa utveckla ny programvara för att använda via ett 

webbgränssnitt och att man istället kunde använda existerande 

system för på ett enkelt sätt göra dessa mer tillgängliga. Detta 

kan uppnås genom att man komponentifierar existerande 

programvara och använder dessa komponenter på olika sätt på 

en webbserver eller liknande. 

Den här rapporten presenterar möjligheter och lösningar på 

problem som kan uppkomma när man ska komponentifiera ett 

existerande system och göra det tillgängligt via ett 

webbgränssnitt och Internet Explorer på ett internt nätverk. 

Rapporten är ett resultat av ett examensarbete utfört vid 

Institutionen för Datavetenskap (IDA) vid Linköpings 

Tekniska Högskola på uppdrag av GoldPen Computing AB i 

Linköping. 

1.1 Bakgrund 

GoldPen Computing AB är ett företag i Linköping med ca. 15 

anställda. De inriktar sig på applikationer avsedda för 

handdatorer att använda i fält, exempelvis vid projekteringar. 

En kund hos GoldPen Computing AB är Telia AB, som 

använder penndatorer när de är ute och projekterar arbeten. 

Till sin hjälp har de ett system som heter Klipp, f.d. MätBok 

90, som beräknar materialåtgång, materialkostnad, 

arbetskostnad etc. Detta ska göras tillgängligt via ett 

webbgränssnitt, där man ska kunna utföra vissa beräkningar 

med ett antal grundmallar som bas. 

9

10 

1.2 Syfte 

Introduktion 

Syftet med examensarbetet är att identifiera möjligheter och 

problem vid komponentifiering av ett existerande system 

genom att implementera en sådan komponent för det specifika 

fallet beskrivet i kapitel 3.1, Det existerande systemet. Kan 

man göra sin komponentifierade programvara tillgänglig via 

ett webbgränssnitt medför detta att man kan komma åt 

funktionalitet genom sin vanliga webbläsare, exempelvis 

Internet Explorer. Många företag försöker standardisera sin 

datormaskinpark, framför allt när det gäller mjukvara. Kan 

man då göra sina system tillgängliga via webbläsaren behöver 

man alltså inte installera någon programvara för varje 

användare, vilket medför att man kommer undan den 

kostsamma och tidskrävande certifieringsprocessen som varje 

ny programvara måste genomgå. Certifieringsprocessen 

kommer av att man inte vill att nya system ska störa 

existerande. 

Utöver själva komponentifieringen tillkommer även att 

identifiera möjligheter och problem vid utvecklingen av ett 

webbgränssnitt för komponenten. Ett webbgränssnitt medför 

vissa begränsningar när det gäller exempelvis 

användargränssnitt, men även vissa programmeringstekniska 

begränsningar såsom datatyper, händelser mm. 

1.3 Läsanvisningar 

Rapporten vänder sig framför allt till personer som är 

intresserade av komponentifiering och webbprogrammering. 

För att få någon behållning av rapporten bör alltså en viss 

kunskap inom dessa områden finnas, samt inom 

utvecklingsarbete i Windowsmiljö. Det antas även att läsaren 

har en viss programmeringsvana i C++ (Microsoft Visual 

C++ [5]). 

Återstoden av rapporten disponeras på följande sätt: 

Kapitel 2: Problemspecificering 

Omfattar en specificering av problemet samt en beskrivning 

av målet med examensarbetet.

Kapitel 3: Förstudie 

Introduktion 

Omfattar en beskrivning av arbetet under förstudieperioden. 

Här beskrivs även det existerande systemet kort, en del 

komponenttekniker samt val av programspråk och 

utvecklingsmiljö. Här återfinns även de tekniker som valdes 

bort tillsammans med en kort motivering för dessa val. 

Kapitel 4: Sammanfattning/slutsatser av förstudie 

Här återges vad som framkom under förstudieperioden samt 

vilka slutsatser som kunde dras av detta. Under förstudien 

lästes en hel del material inom respektive område vilket 

resulterade i att vissa problem uppdagades. Slutsatserna ligger 

till grund för arbetet under prototyputvecklingsperioden och 

utvecklingsperioden. 

Kapitel 5: Prototyputveckling 

I det här kapitlet beskrivs arbetet med att utveckla prototyper. 

Det ingår då en kort beskrivning av varje teknik som testats 

och sedan en utvärdering av dessa. Utvärderingen är till för att 

välja teknik för utvecklingsarbetet av en färdig komponent 

tillsammans med ett webbgränssnitt. 

Kapitel 6: Implementation av exempelsystem 

Här beskrivs hur ett exempelsystem skapades. Kapitlet 

innehåller design, implementation och testning av detta. 

Systemet är uppdelat i två huvuddelar, en komponentdel, 

innehållande en eller flera komponenter, och ett 

webbgränssnitt. Båda dessa beskrivs här. 

Kapitel 7: Utvärdering och förbättringsförslag 

Här återfinns en utvärdering av exempelsystemet, baserat på 

bl.a. information från en applikation för att simulera många 

simultana användare på en webbserver, Microsoft Web 

Application Stress Tool [26]. I kapitlet ges även två förslag på 

hur systemet skulle kunna byggas upp med hjälp av DCOM 

och ActiveX tillsammans med DCOM. 

11

12 

Introduktion 

Kapitel 8: Begreppslista 

Här beskrivs viktiga och vanligt förekommande begrepp som 

behövs för att underlätta förståelsen av resten av dokumentet. 

Kapitel 9: Referenser 

I det här kapitlet återfinns alla externa referenser till andra 

dokument, böcker och webbsidor. 

Appendix A: COM/DCOM 

Här beskrivs Microsofts tekniker för komponenter, COM och 

DCOM. Framför allt beskrivs COM eftersom det är denna 

modell som används för komponentifiering av ett system i det 

här fallet.

Problemspecificering 

2 Problemspecificering 

Detta kapitel formulerar problemställning och mål med 

examensarbetet. 

2.1 Problemformulering 

Examensarbetet avser att komponentifiera ett existerande 

system för att göra valda delar av detta tillgängligt via ett 

webbgränssnitt. Det existerande systemet används idag som 

en fristående applikation och fungerar på datorer med 

operativsystem ur Microsofts Windowsfamilj, Windows 95, 

98, NT och 2000 (se 3.1, Det existerande systemet). 

För att genomföra komponentifieringen finns ett antal olika 

tekniker och utvecklingsmiljöer att tillgå. Problemet kan 

därför delas upp i följande delproblem: 

• Val av utvecklingsmiljö utifrån operativsystem, 

programmeringsspråk, IDE (Integrated Development 

Environment) m.m. 

• Val av komponentteknik utifrån vald utvecklingsmiljö 

• Implementation av komponent 

• Implementation av webbgränssnitt 

2.1.1 Val av utvecklingsmiljö 

Beroende på i vilken miljö lösningen skall fungera kan olika 

programmeringsspråk och IDE användas. Vid valet bör alltså 

vägas in vilket operativsystem som komponenten skall 

fungera i och vilken webbserver webbgränssnittet ska ligga 

på. Även utvecklingsmiljö för det existerande systemet spelar 

en avgörande roll. 

2.1.2 Val av komponentteknik 

För att skapa en bakgrund till valet av komponentteknik för 

den slutgiltiga komponenten bör en delmängd av de tänkbara 

teknikerna testas och utvärderas. Resultatet från denna 

utvärdering ligger till grund för vilken teknik som kommer att 

användas vid utvecklingen av en användbar komponent. 

Viktigt att ta hänsyn till här är stöd för t.ex. databaskopplingar 

13

14 


och kodåtervinning. För att kunna göra det här valet ska olika 

tekniker testas genom att ett antal prototyper implementeras. 

2.1.3 Implementation av komponent 

När valet av komponentteknik (se 2.1.2, Val av 

komponentteknik) gjorts ska en komponent implementeras. 

Denna ska fungera i åtminstone en simulerad miljö. 

Komponenten ska dock vara utvecklad så att den lätt kan 

införas i den slutgiltiga lösningen på komponentifieringen av 

systemet. 

2.1.4 Implementation av webbgränssnitt 

För att utvärdera hur komponenten fungerar ska ett 

webbgränssnitt implementeras, där denna används. 

Webbgränssnittet ska innehålla valda delar av funktionaliteten 

hos det existerande systemet. När man vill använda sin 

komponent via webben måste man följa vissa regler, framför 

allt när det gäller datatyper och säkerhet. 

2.2 Målbeskrivning 

Examensarbetet kan delas upp i ett antal delmål utifrån 

problemformuleringen enligt: 

1. Undersökning och utredning av tillgängliga teknologier 

och hur implementationen bör utföras. I första hand ska 

COM/DCOM behandlas för att användas från 

exempelvis ASP (Active Server Pages). 

2. Någon eller några delar av systemet är simulerat. En 

testmiljö skapas för att kontrollera om tekniken, som 

togs fram under punkt 1, fungerar. 

3. Någon eller några delar av systemet är implementerat 

som avsett, samtidigt som några delar simuleras i 

testmiljön. 

4. De flesta delarna av systemet fungerar som avsett och 

kan visas i en fingerad miljö. 

5. Ett demonstrationsexemplar har gjorts i skarp miljö. 

Ett realistiskt mål är att uppnå minst nivå 3.


2.2.1 Undersökning av tillgängliga tekniker 

Det här målet kan återkopplas till första och andra punkten i 

problemformuleringen (se 2.1.1, Val av utvecklingsmiljö, och 

2.1.2 Val av komponentteknik). När målet uppnåtts bör en 

delmängd av tillgängliga tekniker ha testats genom att 

prototyper utvecklats. Dessa prototyper ska utvärderas för att 

senare val av teknik för den slutliga komponenten ska kunna 

göras på ett bra sätt. 

2.2.2 Simulering i en testmiljö 

Det här målet är till för att noggrannare testa den teknik som 

valdes under tidigare undersökning (se 2.2.1, Undersökning 

av tillgängliga tekniker). Om den valda tekniken inte skulle 

visa sig fungera som förutsett finns fortfarande möjlighet att 

byta teknik. 

2.2.3 Delar av komponenten implementerade som avsett 

Med det här målet avses att komponentifieringen är 

genomförbar och viss grundläggande funktionalitet är 

implementerad. Sådan funktionalitet kan vara att 

komponenten kan användas med vissa parametrar satta till 

standardvärden. 

2.2.4 De flesta delarna av komponenten implementerade 

Komponenten är i stort sett färdig. Fortfarande förekommer 

en del standardvärden på vissa parametrar samt att de mest 

komplicerade delarna av det existerande systemet inte finns 

tillgängligt via webbgränssnittet. 

2.2.5 Demonstrationsexemplar av komponenten 

Komponenten är så pass färdig och webbgränssnittet 

implementerat för att kunna användas på ett tillfredsställande 

sätt. 

15

3 Förstudie 

Förstudie 

Förstudien syftar till att presentera information om olika 

valmöjligheter för delproblemen specificerade i 

problemformuleringen (se 2.1, Problemformulering) samt att 

sätta sig in i det existerande systemet som skall användas för 

utredningen. 

3.1 Det existerande systemet 

Systemet som ska göras tillgängligt via ett webbgränssnitt 

heter Klipp och är ett projekteringssystem som används av 

Telia AB. Med hjälp av detta system kan man beräkna arbets- 

och materialkostnader för att exempelvis lägga ned en kabel 

mellan två punkter i terrängen. Man beskriver då terrängen 

längs den sträcka som ska projekteras, exempelvis genom att 

tala om var och hur mycket som behöver sprängas, hur många 

vägtrummor som måste läggas ned m.m. Klipp hette tidigare 

MätBok 90 (MB 90) och var ett DOS-baserat system, som i 

senare versioner har flyttats över till 32-bitars Windowsmiljö. 

Systemet är uppbyggt av ett antal moduler och databaser (se 

Figur 1). I systemet finns två databaser som existerar hela 

tiden och en projektdatabas för varje projekt. 

I systemdatabasen (Sysbaser) finns, förutom tillgängligt 

material för arbetet, ett antal mallar som kan användas för att 

snabbt skapa sig en uppfattning om kostnaden för vissa 

projekt. Här återfinns bland annat projekt som husmontering, 

nedläggning av OPTO-kabel i tätort/glesbyggd etc. Denna 

funktion är det som i första hand eftersöks hos den komponent 

och det webbgränssnitt som ska utvecklas under 

examensarbetet. I den andra systemdatabasen, krypterad 

CTree, finns priser för arbeten och material för respektive 

entreprenör. 

I figuren nedan (Figur 1) syns att systemet består av fem 

moduler: 

• MB3: Användargrässnittet. 

• MB3MODEL: Beräkningsmodeller, 

projektinformation. 

• MB3DB: Databashantering. 

• MB3PRDB: Databashantering. 

17

18 

Klipp 

MB3UTIL 

Förstudie 

• MB3UTIL: Kvarleva från tidigare versioner. Innehåller 

bland annat klasser för stränghantering m.m. 

Sysbaser 

med material, 

mallar mm (Access) 

MB3 

MB3MODEL 

MB3DB MB3PRDB 

Krypterad DB 

med priser mm (CTree) 

Figur 1. Moduler och kopplingar mellan dessa i Klipp 

Alla moduler utom MB3 är implementerade och tillgängliga 

som statiska kodbibliotek (lib-filer). Dessa bibliotek länkas in 

i MB3 som sedan kan använda funktionalitet hos dessa. 

Det som eftersträvas är en modul att koppla till MB3MODEL 

som gör det möjligt att komma åt funktionalitet från denna 

och nedåt i hierarkin via ett webbgränssnitt. 

3.2 Val av utvecklingsmiljö 

Projekt (Access) 

WWW 

Komponent 

När det gäller valet av utvecklingsmiljö finns ett antal faktorer 

att väga in. Bland dessa märks speciellt:

• Operativsystem 

• Tillgänglighet 

• Dokumentation 

• Förkunskap 

Förstudie 

De operativsystem som kan vara aktuella för lösningen är 

Microsoft Windows, Unix och Linux. Den existerande lösning 

finns just nu i versioner som fungerar på datorer med olika 

versioner ingående i Microsoft Windows-familjen, så som 

Windows 95, 98 och 2000 Professional/Server. Även på 

serversidan, alltså den dator där webbservern för 

webbgränssnittet ska köras, används Microsoft Windows med 

Microsoft Internet Information Service (IIS) [21] installerat. 

För Microsoft Windows finns även tillgängligt 

utvecklingsverktygen Microsoft Visual Studio 6.0 och 

Microsoft Visual Studio.NET 7.0 [5]. Till båda dessa finns 

dokumentation tillgänglig via Microsoft Developer Network 

Home (MSDN Home) [1] på Internet samt Microsoft 

Developer Network Library (MSDN Library) som installeras 

lokalt på utvecklingsdatorn. Det senare ingår då som en del i 

Microsoft Visual Studio. 

Med ovanstående fakta var valet en självklarhet. 

Operativsystemet som ska användas är Microsoft Windows 

och utvecklingsverktyget är Microsoft Visual Studio. 

Intressant att nämna är att Microsoft Visual Studio.NET 7.0 

för tillfället endast finns i s.k. betaversion och att ingen på 

företaget tidigare använt denna miljö för utvecklingsarbete. 

Det var först tänkt att version 7.0 skulle testas under 

prototyputvecklingen, framför allt under utvecklingen av 

webbgränssnittet. Detta genomfördes dock inte (se 5.1.3, 

Visual Studio.NET 7.0 (C# Web Application)). 

3.3 Val av komponentteknik 

En komponent är en modul, bestående av ett eller flera objekt 

eller klasser, som kan ses som en s.k. svart låda. 

Komponenten har ett väldefinierat gränssnitt (interface) 

genom vilket kommunikation i form av metodanrop kan ske. 

De tekniker som finns tillgängligt inom komponentifieringen 

av system skiljer sig en del åt i implementation och 

19

20 

Förstudie 

underliggande struktur när det gäller anropskedjor m.m. 

Tillgängliga tekniker för komponentifieringen är: 

• COM/DCOM 

• ActiveX 

• CORBA 

• JavaRMI 

m.fl. 

Eftersom valet av utvecklingsmiljö (se 3.2, Val av 

utvecklingsmiljö) föll på Microsoft Windows tillsammans 

med Microsoft Visual Studio föll valet av komponentteknik 

på COM/DCOM (se 9, Begreppslista, samt appendix A, 

COM/DCOM) 

3.3.1 Tekniker som valdes bort 

I avsnittet ovan listades ett antal tekniker för 

komponentifieringen. Av dessa valdes en ut eftersom de andra 

av olika anledningar inte ansågs uppfylla de krav som ställs 

på komponenten. 

1. ActiveX – Den här tekniken har ungefär samma 

egenskaper som COM/DCOM-komponenter men är 

inte lika generell som dessa. Exempelvis krävs det att 

klienten har den aktuella ActiveX-komponenten 

registrerad för att kunna använda den. Det finns även 

vissa begränsningar på vilket sätt en ActiveXkomponent 

kan användas i webbgränssnittet, 

exempelvis i en s.k. ASP (Active Server Page). Dessa 

begränsningar kommer av att en ActiveX-komponent 

kan innehålla grafiskt användaregränssnitt (GUI), vilket 

inte är tillåtet om man vill att komponenten ska 

exekvera på en server. 

2. CORBA – Det här är egentligen inte någon komponent 

utan en standard definierad av The Object Management 

Group (OMG) [2] för att möjliggöra kommunikation 

mellan en server och en klient. CORBA är speciellt 

användbart när lösningarna implementeras i Java. För 

en jämförelse mellan DCOM och CORBA se [3]. 

3. JavaRMI – Det här är Sun Microsystems [4] modell för 

distribuerade komponenter och objekt. Eftersom 

utvecklingsverktyget för uppgiften är vald till Microsoft

Förstudie 

Visual Studio så kan inte denna renodlade Javateknik 

användas. En fördel med JavaRMI är att modellen gör 

att lösningarna blir helt plattformsoberoende. Detta 

gäller även för CORBA-lösningar implementerade i 

Java. 

3.4 Microsoft Visual Studio 

Microsoft Visual Studio är ett kraftfullt verktyg som erbjuder 

utveckling av allt från stora system med flera utvecklare ner 

till små enkla program utvecklade av en person. Verktyget har 

funnits i ett antal versioner där den senast släppta versionen är 

version 6.0. Ute nu finns dock betaversioner av .NET 7.0, som 

beräknas släppas i fullständig version inom kort. .NET 7.0 

innehåller bl.a. ett helt nytt programspråk, C# (C Sharp), som 

är ett språk utvecklat för att underlätta utvecklingen av 

webbapplikationer. Det är en blandning mellan Java och C++. 

Mer information om Microsoft Visual Studio finns på 

Microsoft Developer Network [1] samt på Microsoft Visual 

Studio Home Page [5]. 

3.5 COM/DCOM 

COM (Component Object Model) och DCOM (Distributed 

Component Object Model) [6] är två olika modeller för 

komponentutveckling. DCOM är en utökning av COM med 

stöd för distribuerade komponenter. COM ska vara en 

plattformsoberoende, objektorienterad modell, men vänder sig 

framför allt till utvecklare som använder sig av Visual Basic 

eller C++. Detta gör att komponenter enligt COM främst 

används för system som körs under Microsoft Windows. För 

mer information se appendix A, COM/DCOM. 

21

Sammanfattning/slutsatser av förstudie 

4 Sammanfattning/slutsatser av förstudie 

Det här kapitlet syftar till att sammanfatta vad som framkom 

under förstudiefasen samt vilka slutsatser man kan dra av 

detta. 

Under förstudieperioden lästes mycket material, genomgång 

av det existerande systemet förekom samt s.k. debuggning 

(debugging, avlusning) av detsamma. Den debugger som 

användes är den som ingår i Microsoft Visual Studio 6.0 [5]. 

Med detta som grund kunde vissa slutsatser dras. Dessa ligger 

sedan till grund för det fortsatta arbetet, framför allt under 

utvecklingsperioden, men även under prototyputvecklingen. 

4.1 Utvecklingsmiljö 

Valet av utvecklingsmiljö var relativt lätt att göra. För själva 

komponenten är det Microsoft Visual Studio 6.0 [5] som är 

aktuellt. Anledningen till detta val är att det existerande 

systemet är utvecklat i denna miljö. Under förstudien har även 

Microsoft Visual Studio.NET 7.0 studerats och det 

existerande systemet har kompilerats med hjälp av den 

kompilatorn. Själva kompileringen gick bra efter ett fåtal 

ändringar och en del inställningar framför allt när det gäller 

länkningen av programmet. Det som var avgörande för valet 

av version 6.0 av utvecklingsmiljön var att det 

omkompilerade systemet krävde nya versioner av vissa s.k. 

DLL:er. Dessa DLL:er finns oftast inte tillgängliga i dagsläget 

om inte version 7.0 är installerat på respektive dator. 

Vad som dock kan vara intressant att utvärdera är användning 

av version 7.0 när det gäller utvecklingen av 

webbgränssnittet. Detta eftersom den här versionen innehåller 

mycket bättre stöd för utveckling av sådana system. 

4.2 Komponentteknik 

Även valet av komponentteknik var relativt enkelt att göra. 

Här föll valet, som tidigare nämnts, på COM [6] (se 3.5, 

COM/DCOM). Detta eftersom det finns stöd för sådan 

utveckling i den valda utvecklingsmiljön. De delar av det 

existerande systemet som ska ingå i komponenten existerar i 

form av statiska lib-filer. Dessa filer använder sig av DLL- 

23

24 


filer av en något äldre version, som nämndes ovan (se 4.1, 

Utvecklingsmiljö). 

4.3 Upptäckta problem under förstudien 

Under förstudien uppdagades ett antal problem. En del av 

dessa löstes medan andra kan lösas längre fram i tiden, efter 

det att detta examensarbete avslutats. 

Problemen är: 

• Flyttning av projekt i Visual Studio mellan maskiner 

inte helt problemfritt. 

• Det existerande systemets uppbyggnad (statisk eller 

dynamisk länkning). 

• Datatyper som inte stöds i ASP [7] (VBScript och 

JScript [8]). 

Dessa förklaras kort nedan tillsammans med eventuella 

lösningar. 

4.3.1 Flyttning av projekt i Visual Studio 

Trots att all källkod versionshanteras med hjälp av Microsoft 

Visual SourceSafe 6.0 [9] kunde inte flytten av 

källkodsprojektet genomföras på ett enkelt sätt. Det visade sig 

fattas en del kodbibliotek samt att vissa delar av det 

existerande systemet var tvunget att ändras. 

Lösning 

Det finns för närvarande ingen förklaring och därmed ej heller 

någon lösning på detta, men projektet fungerar i alla fall 

tillfredsställande tills vidare. Det kan bli aktuellt att senare 

försöka lösa dessa problem. Det kan också bli tvunget att göra 

detta. En sista utväg är att helt enkelt testa att flytta till en 

annan dator och flytta över arbetet till denna. 

4.3.2 Det existerande systemets uppbyggnad 

Som delarna i det existerande systemet är uppbyggt för 

tillfället så kan inte dynamisk länkning av dessa åstadkommas 

(se 3.1, Det existerande systemet). Delarna är uppbyggda på 

ett sådant sätt att de ingår i den exekverbara enheten. Detta 

medför att den komponent som ska utvecklas måste


kompileras om varje gång en viktig uppdatering av någon del 

i det existerande systemet utförs. Detta är dock inget stort 

problem eftersom komponenten är avsedd att finnas i ett fåtal 

exemplar på centrala webbservrar. Det skulle vara ett avsevärt 

större problem om komponenten skulle behöva installeras på 

alla klientdatorer som ska använda denna. 

Lösning 

Det finns en lösning till detta problem, men det innebär 

mycket arbete. Det bör påpekas att uppdelningen och därmed 

länkningen såg annorlunda ut i tidigare versioner av det 

existerande systemet, men detta innebar en del problem. Man 

valde då att lösa dessa genom att statiskt länka in delarna i 

den exekverbara enheten. Man kan lösa problemet genom att 

man kapslar in de olika delarna i enheter som kan länkas 

dynamiskt. Man behöver alltså inte länka om hela systemet, 

utan bara kompilera om de delarna som ändrats. Det krävs 

dock en hel del arbete eftersom man då måste mappa varje 

metod och attribut i den existerande delen mot motsvarande 

metoder och attribut i inkapslingsbiblioteket. Man vet inte 

heller hur mycket arbete som krävs för att få de nu existerande 

delarna att fungera tillsammans som skilda dynamiskt länkade 

enheter. Detta eftersom det förekommer ett stort antal 

kopplingar mellan dessa och sådana kopplingar kan ställa till 

en hel del problem. 

4.3.3 Datatyper i ASP 

Eftersom de scriptspråk som ingår i ASP inte är lika kraftfulla 

som ett vanligt programmeringsspråk så finns det en del 

undantag när det gäller framför allt datatyper. När det ska 

finnas kommunikation mellan COM och ASP så är det 

datatypen VARIANT (se appendix A.8.1, VARIANT) som är 

aktuell. Detta är en typ som kapslar in en underliggande 

struktur som i sin tur kan innehålla ett antal olika typer av 

data. Typen VARIANT används för att den ser likadan ut utåt, 

oberoende av vilken datatyp som egentligen ingår i den. I 

VARIANT finns en typ som heter VT_ARRAY. Detta gör det 

möjligt att skicka arrayer genom komponentens gränssnitt. 

Denna typ är mycket aktuell i just den här komponenten som 

ska utvecklas. Det som ställer till problem här är att man 

måste använda en s.k. SafeArray på komponentsidan. Detta är 

relativt komplicerat, vilket gör att det bör undvikas. 

25

26 

Lösning 


Det finns lösningar på detta problem, enligt nedan. 

1. Man kan låta komponenten skicka tillbaka HTML-kod i 

form av en sträng. Denna strängen kan sedan visas med 

hjälp av ASP eftersom strängar enkelt kan hanteras. 

2. Man kan låta komponenten skicka tillbaka en sträng 

formaterad på ett speciellt sätt. Strängen tas sedan om 

hand av scriptspråket på ASP-sidan som genererar 

önskad HTML-kod. 

3. Man kan låta komponenten skicka tillbaka en sträng i 

XML-format. Strängen används sedan genom att man 

specificeras ett s.k. stylesheet som presenterar 

informationen på önskat sätt. 

Den första lösningen är enkel men inte så flexibel. Skulle man 

vilja presentera informationen från komponenten på ett annat 

sätt kräver det att man skriver om koden i komponenten. 

Den andra lösningen är bättre men inte heller den så flexibel. 

För att ändra på hur informationen presenteras måste man 

ändra i scriptet. 

Den tredje lösningen är den som är effektivast och mest 

flexibel. Den kräver dock mer arbete och kunskap inom XML. 

Fördelen med XML är att det är speciellt avsett för att 

presentera mycket information på olika sätt. Det är även 

mycket flexibelt eftersom man kan ha flera olika stylesheets. 

Ett stylesheet är en definition på hur man vill presentera 

information i ett XML-dokument, som tillåter att man 

bestämmer färger, indentering etc. Man kan alltså göra ett 

antal stylesheets tillgängliga och låta respektive användare 

välja just sitt favoritutseende bland dessa. 

4.4 Sammanfattning 

Som beskrivits ovan har ett antal val gjorts och vissa problem 

upptäckts. Baserat på dessa val kommer en 

prototyputvecklingsperiod påbörjas. Eftersom val av 

komponentteknik är gjort så kommer inte några andra 

tekniker att testas inom detta område. Det som kommer att


testas med hjälp av prototyper är olika tekniker på klientsidan 

(se 4.3.2, Det existerande systemets uppbyggnad, och 4.3.3 

Datatyper i ASP). Nedan ges fyra förslag på sådana: 

1. Utveckla en prototyp med hjälp av ASP. 

2. Utveckla en prototyp med hjälp av ASP och XML. 

3. Utveckla en prototyp med hjälp av Microsoft Visual 

Studio.NET 7.0 [5]. 

4. Utveckla en prototyp med hjälp av Microsoft Visual 

Studio.NET 7.0 [5] och XML. 

Möjlighet ett innebär att man sköter presentationen på 

komponentsidan och skickar tillbaka HTML-kod i form av en 

sträng. 

Möjlighet två innebär att man från komponenten skickar 

tillbaka informationen som en XML-formaterad sträng vilken 

presenteras med hjälp av ett stylesheet. 

Möjlighet tre innebär att man skapar en s.k. ”ASP.NET Web 

Application” i vilken man skriver programkod i Microsofts 

nya programspråk C# [5]. En sådan applikation kan sedan 

användas tillsammans med exempelvis Microsoft IIS. Med 

hjälp av C#-kod formaterar man strängen som skickas tillbaka 

från komponenten. 

Möjlighet fyra innebär att man utökar möjlighet tre med att 

låta XML ta hand om formateringen och presentationen av 

informationen. 

Dessa fyra möjligheter planeras att användas för 

prototyputvecklingsperioden som följer. 

27

Prototyputveckling 

5 Prototyputveckling 

Det här avsnittet beskriver arbetet under 

prototyputvecklingsperioden. Prototyperna var först meningen 

att testa vilka komponenttekniker som kunde passa för det 

aktuella systemet. Eftersom det existerande systemet ser ut 

som det gör idag så är det bara en teknik som är aktuell, 

nämligen COM/DCOM. Detta gör att de prototyper som 

utvecklas under den här perioden kommer att bli sådana som 

finns på klientsidan av systemet, alltså i webbgränssnittet. Där 

finns ett antal olika lösningar och förslag till sådana (se 4.4, 

Sammanfattning). Komponenten som kommer att användas 

för utvärdering av webbgränssnittet kommer att vara enkel. 

5.1 Webbgränssnittet 

På klientsidan, webbgränssnittet, finns ett antal olika 

lösningar att tillgå. Bland dessa finns framför allt tre områden 

att testa: 

1. ASP (Active Server Pages) 

Denna metod bygger på att man med hjälp av 

scriptspråk, antingen VBScript eller JScript [8], bygger 

upp webbsidorna (se 5.1.1, ASP (Active Server 

Pages)). 

2. XML (eXtensible Markup Language) 

Detta är en standard som möjliggör att man strukturerar 

stora mängder data enligt en trädliknande struktur. 

Denna data kan sedan presenteras på olika sätt genom 

att man använder stylesheets (se 5.1.2, XML 

(eXtensible Markup Language)). 

3. Visual Studio.NET 7.0 (C# Web Application) 

C# och Visual Studio.NET 7.0 [5] är Microsofts nya 

programspråk och utvecklingsverktyg. Verktyget 

möjliggör att man kan skapa kraftfulla 

webbapplikationer genom att skriva C#-kod (se 5.1.3, 

Visual Studio.NET 7.0 (C# Web Application)). 

Med hjälp av dessa tre tekniker ska ett antal prototyper 

utvecklas och utvärderas. Teknikerna beskrivs utförligare 

nedan och efter det kommer en kort utvärdering tillsammans 

med val av teknik för implementationen av den färdiga 

komponentens webbgränssnitt. 

29

30 


5.1.1 ASP (Active Server Pages) 

Active Server Pages är som namnet antyder ett scriptspråk 

som exekverar på servern i en webbapplikation. Det finns 

framförallt två språk som man använder för lösningar i 

Windowsmiljö. Dessa är VBScript [16] och JScript [15] och 

ingår i Microsofts infrastruktur för scriptspråk, Windows 

Script [8]. Med denna som grund kan man utveckla kraftfulla 

och flexibla webbapplikationer som innehåller bland annat 

databasaccess, användning av komponenter och andra 

programmoduler. Aktuell version för Windows Script är 

version 5.6, som finns tillgänglig för nedladdning på 

Windows Scripts hemsida [8]. I detta paket ingår VBScript 

5.6, JScript 5.6, Windows Script Components 5.6, Windows 

Script Host 5.6 och Windows Script Runtime Version 5.6. 

Det som gör ASP kraftfullt för utveckling av webbgränssnitt 

som använder sig av komponenter, COM eller DCOM, är 

möjligheten att skapa instanser av dessa objekt och anropa 

metoder från scripten. Det gör man genom metoden: 

Set so = 

Server.CreateObejct(servername.typename[,location]) 

Detta ger en referens till komponentobjektet och man kan 

sedan anropa metoder i detta med hjälp av so, enligt: 

so.Metod(arg1,arg2,...) 

Genom detta kommer man åt funktionalitet i sin komponent. 

Se vidare 5.2.1, Prototyp 1 - ASP-version, för att se hur ASP 

användes i den första prototypen på webbgränssnitt. 

5.1.2 XML (eXtensible Markup Language) 

XML [11] kan ses som en utökning av HTML [18]. Det är en 

universell standard för att på ett strukturerat sätt presentera 

information på webbsidor. Språket utvecklades av XML 

Working Group, tidigare känd som SGML Editorial Review 

Board, bildad 1996 under överseende av W3C [10]. Ett av 

målen med XML var att det skulle vara lätt att använda på 

Internet och att det skulle stödja en bred variation av 

applikationer. Det som gör XML speciellt kraftfullt är 

möjligheten att definiera egna s.k. taggar i en datasträng som


man med hjälp av ett stylesheet kan formatera och visa på en 

webbsida. Det stylesheet som används då är XSL [19], 

tillsammans med transformationerna i XSLT, XSL 

Transformations. För exempel och hur XML och XSL 

användes för prototyputveckling se 5.2.2, Prototyp 2 - XMLversion. 

5.1.3 Visual Studio.NET 7.0 (C# Web Application) 

Visual Studio.NET 7.0 [20] är Microsofts nya 

utvecklingsmiljö som bland annat innehåller det nya 

programspråket C# (C Sharp). Med hjälp av detta språk kan 

man utveckla webbapplikationer som bygger på en ny version 

av ASP, ASP.NET. I utvecklingsmiljön ingår bland annat 

verktyg för att rita upp användargränssnittet för 

webbapplikationen. Detta gör det snabbt och lätt att skapa 

grundstommen för ett webbgränssnitt. Till detta gränssnitt kan 

man koppla funktionalitet, meddelandehanterare (Message 

Handlers) m.m. 

Det var från början tänkt att en prototyp skulle utvecklas med 

hjälp av Visual Studio.NET 7.0, men detta kommer inte att 

genomföras. Anledningen är att installationen av miljön 

skapade många problem med kompatibilitet och konfigurering 

av webbservern som ska användas i systemet, Microsoft 

Internet Information Service (IIS) även kallad Windows Web 

Services [21]. 

5.2 Prototyperna 

Som nämndes ovan kommer ingen prototyp utvecklas med 

hjälp av Visual Studio.NET 7.0. Två andra prototyper har 

utvecklats, en ren ASP-version och en ASP/XML-version. 

Dessa två beskrivs nedan (se 5.2.1, Prototyp 1 - ASP-version, 

och 5.2.2, Prototyp 2 - XML-version). 

Ett mål med prototyperna som utvecklades var att utseendet 

på de webbgränssnitt som skapades skulle se så lika ut som 

möjligt. Detta för att kunna jämföra vilken teknik som passar 

bäst när det gäller framför allt programstruktur och 

vidareutvecklingsmöjligheter. 

Gemensamt för båda prototyperna är att de använder sig av 

samma komponent (se 5.2.3, Komponentprototyperna). Detta 

visar att webbgränssnittet kan bytas ut till godtycklig teknik, 

31

32 


bara man vet formatet på den information som komponenten 

genererar. Komponenten är uppbyggd på ett sådant sätt att 

den returnerar informationen i form av strängar. 

Informationen i strängarna grupperas med hjälp av start- och 

sluttaggar. En fördel med att returnera strängar som innehåller 

mycket information är att man slipper anropa komponenten 

många gånger, vilket skulle belasta servern onödigt mycket. 

Att returnera strängar genom ett COM-gränssnitt är enkelt och 

relativt snabbt. Det är även enkelt att på komponentsidan 

bygga upp denna sträng. Det finns exempelvis inte något 

enkelt sätt att returnera arrayer genom ett gränssnitt. Dessa 

måste kapslas in i s.k. SafeArrays, vilka är komplicerade att 

använda (se 4.3.3, Datatyper i ASP). 

5.2.1 Prototyp 1 - ASP-version 

Prototypen byggdes så att all HTML-kod genererades på 

serversidan. I figuren nedan (Figur 2) åskådliggörs 

prototypens uppbyggnad. 

Webbserver 

ASP 

COM 

HTML 

Klient 

Figur 2. Prototyp 1 översikt 

VBScript används för att generera HTML-koden från servern. 

Detta scriptspråk visade sig vara kraftfullt när det gäller 

stränghantering och strängmanipulation. I VBScript ingår s.k. 

regular expressions, som kan användas för att söka efter 

mönster i strängar och ersätta dessa mönster med godtyckliga 

delsträngar eller tecken.


Med hjälp av detta filtrerades informationen från 

komponenten och den önskade delen presenterades med hjälp 

av HTML-kod. Nedan syns ett exempel på hur en webbsida 

från prototyp 1 ser ut. 

Figur 3. Exempel på webbsida genererad i prototyp 1. 

Så länge prototypen var relativt liten kunde man skapa 

välstrukturerad VBScript-kod, men ju större den blev desto 

svårare var det att hålla strukturen. Exempel på detta är den 

något komplicerade metoden att plocka fram relevant 

information ur strängen som komponenten genererade. Det 

finns inget enkelt sätt att hämta information från en tagg utan 

man var tvungen att använda sig av regular expressions på ett 

ganska ologiskt sätt. Sådana saker gör att VBScript-koden blir 

långsam och ogenerell. Visserligen kan datasträngen från 

komponenten ändra utseende, exempelvis genom att man 

lägger till nya taggar, men det kan inte behandlas på ett 

generellt sätt. 

33

34 


Versionen av prototypen som syns i figuren ovan (Figur 3) är 

inte speciellt invecklad och innehåller inte så mycket 

funktionalitet. Trots detta behövdes ca. 30 % fler rader 

programkod för att skapa den jämfört med versionen i XML, 

beskriven nedan (5.2.2 Prototyp 2 - XML-version). Detta trots 

att XML-versionen innehåller mer funktionalitet och att 

användargränssnittet är bättre. Här följer ett exempel på kod 

för att plocka ut information ur en tagg. 

Function GetData(tag, data) 

Set regEx = new RegExp 

regEx.Pattern = ".*" 

Set resultCollection = regEx.Execute(data) 

Set result = resultCollection.Item(0) 

result = Replace(result,"","") 

result = Replace(result,"","") 

GetData = result 

End Function 

Listning 1. Funktion för att plocka fram information från en tagg. 

I listningen ovan (Listning 1) ser vi att det krävs ett regular 

expression och två strängersättningar. Detta är lite oeffektivt 

och en kraftfullare metod för hantering av data vore önskvärt. 

Det första intrycket av ASP var att det var kraftfullt och enkelt 

att skapa webbsidor med, men detta visade sig vara fel i just 

den här tillämpningen. Programkoden blev lång och svår att 

hitta i. Om små ändringar i layouten på sidan skulle göras 

krävdes relativt stora ändringar i koden, samtidigt som detta 

kunde medföra att vissa specialfall inte fungerade. För en mer 

utförlig utvärdering och jämförelse med XML-versionen se 

nedan (5.3 Jämförelse/utvärdering av prototyperna). 

5.2.2 Prototyp 2 - XML-version 

XML-versionen gjordes på ett sådant sätt att utseendet på 

klientsidan skulle vara så likt ASP-versionen som möjligt. 

Den byggdes upp med hjälp av ett litet ASP-program som 

anropade komponenten och skickade vidare datasträngen från 

denna till ett XSL-dokument på klientsidan. Det medförde att 

all informationshantering flyttades från ASP till XML, vilket i 

sin tur medför att utseendet på webbsidan genereras på 

klientsidan. Klienten har en s.k. XML-parser som går igenom 

XML-koden och använder sig av ett stylesheet, en XSL-fil,


för att generera utseendet på webbsidan. I figuren nedan 

(Figur 4) syns uppbyggnaden hos systemet för prototyp 2. 

Webbserver 

Webbserver 

ASP 

ASP 

COM 

COM 

Datasträng Datasträng (XML) 

(XML) 

Figur 4. Prototyp 2, XML-versionen, översikt 

I och med att XML användes flyttades en stor del av arbetet 

över från servern till klienten. Intressant med den här 

lösningen är att den XSL-fil som används för att definiera 

utseendet på webbsidan är helt fristående och kan bytas ut 

mot en annan. Man kan på sätt styra vilken information som 

skall synas och på vilket sätt den ska presenteras totalt 

oberoende av de andra delarna i systemet. Det enda som krävs 

är att man måste veta hur datasträngen är formaterad och vilka 

taggar som ingår i denna. Man behöver inte själv plocka ut 

informationen i taggarna eftersom dessa fungerar som 

matchningsmönster i XSL-filen för att använda olika mallar 

beroende på vilken tagg som parsern träffar på. 

Exempel på datasträng som komponenten genererar syns 

nedan: 

¢£§©¨£ ¥ ¦¢¢£ ¥ ¢£ §£¤¨ 

¡£¢£¤¦¥ 

§©¨£©¢££¥ © ¦© © © ¡£¢£¤¢£©¦¢£ 

¢£ 

¦ ¥ ¤¦££££¨£¤ 

¡£¢£¤¦¥ ¢£§©¨££©© ¥ ¤£¥ ©£££¨£¤ 

©¢£ ¦©£ ©¢£ 

¤¦££¤ ©¥ 

¨££©¨ ¨££©¨ 

¥ ¦¨£¤¡£¢£ 

¥ ¦¨£¤¡£¢£ 

¥ ¥ 

¢ ¢ 

££¦¡£¢£ £¦¡£¢£ 

XSL 

XSL 

”HTML” 

”HTML” 

Klient 

Klient 

35

36 

¢ 

¢ 

¤¦££¤ 

¡£¢£¤¦¥ ¢£§©¨£ 


¡£¢£¤¦¥ ¢£§©¨££©© ¥ ¡ £¤£¥ ©££¨£¤ 

©¢£ ¦©£ ©¢£ 

¤¦££¤ ©¥ 

¨££©¨ ¨££©¨ 

¥ ¦¨£¤¡£¢£ 

¥ ¦¨£¤¡£¢£ 

¤¦££¤ 

¡£¢£¤¦¥ ¢£§©¨£ 

¥ ¥ 

¢ ¢ 

££¦¡£¢£ £¦¡£¢£ 

¡£¢£¤¦¥ ¢£§©¨££©© ¥ £¤£¥ ©££¨£¤ 

©¢£ ¦©£ ©¢£ 

¤¦££¤ ©¥ 

¨££©¨ ¨££©¨ 

¥ ¦¨£¤¡£¢£ 

¥ ¦¨£¤¡£¢£ 

¤¦££¤ 

¡£¢£¤¦¥ ¢£§©¨£ 

¢ 

¢ 

¢ 

¥ ¤¦££ 

¦ 

¢ 

¢£§©¨£ ¥ ¦¢ 

¡£¢£¤¦¥ 

¥ ¥ 

¢ ¢ 

££¦¡£¢£ £¦¡£¢£ 

Listning 2. Datasträngen från komponenten 

Som syns i listningen ovan (Listning 2) är strängens 

formatering väldigt strukturerad och informationen är 

grupperad med hjälp av start- och sluttaggar. Detta är något 

som XML-parsern kräver. 

När det gäller XSL-filen så är det samma krav på denna. 

Varje starttagg måste ha en sluttagg. Detta ger en väldigt bra 

struktur på koden och utökningar eller förändringar är lätt 

införda. Nedan syns ett exempel på en mall som tar hand om


all information i datasträngen inom taggen struktur: 

 

 

 

 

 

 

border-color:'#CCCCCC';border-style:'solid' 

 

 

 

border-top-width:'5px' 

 

 

 

 

 

 

 

 

true 

 

 

 

 

 

 

 

 

 

true 

 

 

 


 

 

 

 

37

38 

 

 



 

 

 

border-color:'#CCCCCC';border-style:'solid' 

 

 

 

 

 

 

varde 

 

 

 

text-align:right 

 

 

8 

 

 

 

 

Listning 3. XSL-kod för att ta hand om informationen i taggen . 

Som syns i listningen ovan (Listning 3) är XSL-koden lika 

strukturerad som datasträngen i listningen ovan denna 

(Listning 2). Listning 3 visar även användningen av 

metoderna i språket. Metoderna är uppbyggda på samma sätt 

som elementen i ett XML-dokument, men dess taggnamn 

börjar med xsl:. Man kan alltså låta sitt stylesheet innehålla 

vilkorssatser (if-satser) och select-satser m.m. enligt ovan. 

Den mängd kod som behövs för att generera webbsidan i 

figuren nedan (Figur 5) är drygt 30 % kortare än den som 

behövdes för prototyp 1 med hjälp av ASP.


Figur 5. Webbsidan som genereras med hjälp av XML och XSL 

Viktigt att påpeka är att det finns ett antal s.k. namespaces för 

XSL. I en första version av prototyp 2 användes ett gammalt 

namespace, som visade sig ha en hel del begränsningar. Bland 

annat fanns inte möjlighet att skriva if-satser innehållande 

AND, OR eller NOT. Detta medförde djupt nästlade if-satser, 

vilket gjorde koden svårtarbetad. För att använda en nyare 

version av namespace krävdes en installation av tre stycken 

DLL-filer, som finns tillgängliga på Microsofts hemsida för 

XML [22]. Installationen uppdaterade XML-parsern för 

Internet Explorer, utan att för den delen göra den äldre 

versionen obrukbar. 

I samband med utvecklingen av prototyp 2 skapades även ett 

utkast på hur en tänkt resultatsida skulle kunna se ut. 

39

40 


Resultatet som ska presenteras här är bland annat 

arbetskostnader och materialkostnader för ett projekt. I 

figuren nedan (Figur 6) syns denna sida. 

Figur 6. Förslag på utseende för resultatsidan efter beräkningar 

på mallen. 

För denna sida ser datasträngen ut enligt nedan: 

¥ £¤¦¢¥ £©¡£¨£¤¦¥ 

¦ ¥ ¤¦££££¨£¤ 

¢£¢£¢£¥ © 

¢£¦¢£ ¤¢£ ¢£¦¢£ ¤¢£ 

¤¢£ 

¤¢£ 

©¢£ ¢¡£ ©¢ 

§©¨©©¤¦¥ ¡£¥ © 

¤£¦¥£§¡¦ ¢¨© £ 

§©¨©©¤¦¥ ¡£¥ ©

¢ 

¢ 

¢ 


¢£© £¥ ©£££¦¨£¤ 

£££ 

£££ 

£££ 

£££ 

¢ 

¢ 

¦¢£¤ ¥£ ¡ ¦¢¤ 

¤¢£ ¢¡£ ¤¢£ 

¦¢£¤ ¨ ¦¢£¤ 

¤¢£ ¢¡£ ¤¢£ 

¢ 

¢£© £¥ ©££££¦¨£¤ 

 

¢£¢£¢£¥ © 

¦ ¥ ¤¦££ 

¦ ¥ ¤¦££££¨£¤ 

¢£¤¦§©¨¦¨ 

¢£¤¦§©¨¦¨£ ¨£¨£ 

¢£¦¢£ ¡ ¢£¦¢£ 

¨££©¨ ¡ ¨££©¨ 

§©¨©©¤¦¥ ¡£¥ © 

£ £ £¢¥¤§¦¡ £¢£ ¥¨ ¢©¤¦£¢ 

§©¨©©¤¦¥ ¡£¥ © 

¨£¤¨££¤¨£©£¤ 

¦ £©¨£ © 

¨£¤¨££¤¨£©£¤ 

¢£¤¦§©¨¦¨£ ¨£¨£ 

¢ 

¢ 

¢ 

¢£¤¦§©¨¦¨ 

¦ ¥ ¤¦££ 

¦ ¥ ¤¦££££¨£¤ 

¢¦¨£¤¦¥ ¢£ 

¢¦¨£¤¦¥ ¢£ ¨£ ¨¨£ 

¢£¦¢£ ¡ ¢£¦¢£ 

¨££©¨ ¨££©¨ 

§©¨©©¤¦¥ ¡£¥ © ¥ §©¨©©¤¦¥ ¡£¥ © 

¢¦¨£¤¦¥ ¢£ ¨£ ¨¨£ 

¢ 

¢ 

41

42 

¢ 

¢¦¨£¤¦¥ ¢£ 

 

¦ ¥ ¤¦££ 

¦ ¥ ¤¦££££¨£¤ 

¡¤¦¥ © 

¦ ¥ ¤¦££ 

¦ ¥ ¤¦££££¨£¤ 

©©¢©£¨£¤ 


©©¢©£¨£ ¨£¨£ 

§©¨©©¤¦¥ ¡£¥ © ¦ ©¦ © ¡ §©¨©©¤¦¥ ¡£¥ £ 

£¤¦¥ ¡ ¢¡ £¤¦¥ 

©©¢©£¨£ ¨£¨£© 

¢ 

¢ 

¢ 

©©¢©£¨£ ¨£¨£¦¦¦¢£ 

© ¤£ 

©©¢©£¨£ ¨£¨£©¦¦¦¦¢£ 

©¢© ¢©£¨£ ¨£¨£ 

¥ ©£¤¥ ©¨ ¦ £© ¡ ¥ ©¤¦¥ ©¨ 

¢£©££¨£ ¨£¨£ 

¢£©£ ¡ ¢£©£ 

¨££©¨ ¥ ¨££©¨ 

¢£©££¨£ ¨£¨£ 

£¤¦¥ ©¦¡ ¡ £¤¦¥ 

§©¨£©¢££¥ © §©¨£©¢££¥ © 

©¢© ¢©£¨£ ¨£¨£ 

¢ 

¢ 

¢ 

©¢© ¢©£¨£ ¨£¨£¦¦¦¢£ 

©¦¡ ¡ 

©¢© ¢©£¨£ ¨£¨£¦¦¦¢£ 

©©¢©£¦¦¦¢£ ¢ ¢¡ ©©¢©£¦¦¢£ 

©©¢©£¨£¤ 

¦ ¥ ¤¦££ 

¦ ¥ ¤¦££££¨£¤ ¡ 

¥ £¨£¤ 

¥ £¨£ ¨£¨£ 

§©¨©©¤¦¥ ¡£¥ © 

£ ¡ ¨§ ¥¨£ ¡£ © ©¨£¦ 

§©¨©©¤¦¥ ¡£¥ © 

¢£¦¢£ ¦¥ ¢£¤ £©£¡ ¥¢ ¢£¦¢£ ¦¥ ¢¤ 

¥ £¨£ ¨£¨£

¥ £¨£¤ 

¦ ¥ ¤¦££ 

¥ £¤¦¢¥ £©¡£¨£¤¥ 

¢ 

¢ 

¢ 


¦¦¢£ ¦¥ £©£ ©¢ ¦¦¢£ ¥ 

Listning 4. Datasträngen för resultatsidan. 

Dataträngarna för de andra sidorna i prototypen har liknande 

utseende, men med andra taggar och värden. 

För en jämförelse och utvärdering av den här prototypen, se 

nedan (5.3 Jämförelse/utvärdering av prototyperna). 

5.2.3 Komponentprototyperna 

Som nämnts ovan är gränssnittet mellan komponenten och 

webbgränssnittet enkelt. Metoderna i komponenten returnerar 

endast strängar, vilket stöds fullt ut av COM. Detta gör det 

enkelt att använda komponenten från VBScript. Det som 

kräver lite extra arbete är inte gränssnittet utåt utan hur man 

använder den existerande programvaran i sin komponent. Det 

som märktes under prototyputvecklingen var att man måste 

vara extra noggrann med minneshanteringen. På det sättet 

prototypkomponenten var implementerad var webbservern, 

Microsoft IIS [21], tvungen att startas om med jämna 

mellanrum, eftersom den blev alltmer minneskrävande ju fler 

gånger komponenten användes. Detta eftersom en ny instans 

av komponenten skapades för varje sida som skulle genereras 

och att de gamla instanserna inte frigjorde använt minne 

ordentligt. 

Det uppdagades även vissa problem med att skapa instanser 

av olika klasser i komponenten som ingick i Klipp. Speciellt 

var det objekt som ingick i det grafiska användargränssnittet 

för systemet. Detta kan möjligtvis lösas genom att låta 

referensen till komponenten ligga i sessionsobjektet för 

webbsidorna. Om man gör så behöver man endast skapa en 

instans av komponenten per webbsession, vilket även minskar 

minnesallokeringarna markant. Detta testades dock inte under 

prototyputvecklingen men kommer att utredas under 

implementationsfasen. 

43

44 


Under prototyputvecklingen implementerades endast en 

komponentprototyp. Denna testades tillsammans med 

webbgränssnittet. Under början av implementationsperioden 

testades dock att utveckla ytterligare en komponent som 

istället för att returnera endast strängar till ASP-scripten 

returnerade XML-objekt. Objekten är egentligen pekare till ett 

gränssnitt, MSXML::IXMLDOMDocument, som följer med 

den XML-parser som ingår i Internet Explorer. Den här 

komponenten visade sig hantera minnet på ett mycket bättre 

sätt än den tidigare versionen. Ett snabbt beslut togs att istället 

använda denna teknik. Det enda som skiljer versionen som 

returnerar strängar från den senare versionen är att man 

extraherar XML-datasträngen på klientsidan istället, med 

hjälp av ett ActiveX-objekt, Msxml2.DOMDocument, som 

man sedan låter XML-parsern formatera på samma sätt som 

tidigare. Detta ActiveX-objekt ingår i XML-parsern och 

medför ingen extra installation på klientsidan. 

5.3 Jämförelse/utvärdering av prototyperna 

För att kunna välja teknik för webbgränssnittet 

implementerades, som nämnts ovan, två prototyper. Dessa 

genererade identiska sidor, men XML-versionen har 

utvecklats längre än den rena ASP-versionen. Prototyperna 

använde sig av samma komponent. Den enda skillnaden här 

var att XML-versionen använde uppdaterade metoder i 

komponenten. Detta eftersom XML är mycket noggrant när 

det gäller start- och sluttaggar i datasträngen från 

komponenten, samt att en del attribut för vissa taggar 

kompletterades allteftersom XML-versionen 

vidareutvecklades. Det bör nämnas att all användning av 

komponenten sköttes med hjälp av VBScript i ASP-filer även 

i XML-versionen. 

När det gäller för- och nackdelar med ASP-versionen så finns 

det egentligen inga fördelar med denna, som inte finns i 

XML-versionen. Däremot finns det en hel del nackdelar. 

Bland dessa nämns några nedan. Det finns givetvis nackdelar 

även med XML-versionen, men dessa är inte lika allvarliga.


Nackdelar med ASP-versionen 

• För att plocka ut önskade delar ur datasträngen krävdes 

regular expressions. Dessa kunde i vissa fall vara 

komplicerade. 

• För att dela upp datasträngen i mindre delar krävdes 

även här regular expressions och användningen av 

dessa var inte helt logisk. Exempelvis var man tvungen 

att först plocka bort startaggar för att sedan dela 

strängen på sluttaggarna. 

• Scriptkoden blev ostrukturerad när sidorna blev alltmer 

komplicerade. Detta gjorde att små förändringar i 

utseendet kunde medföra stora förändringar i koden, 

som i sin tur kunde kräva att vissa specialfall var 

tvungna att behandlas. 

• Det var svårt att hitta fel i koden, eftersom det finns 

mycket begränsade möjligheter att debugga scripten. 

Man kan få webbservern att skriva ut meddelanden om 

var fel uppstår, men dessa är inte alltid lätta att förstå. 

Nackdelar med XML-versionen 

• Det finns ett stort antal versioner av XML-parsers och 

namespaces. Den version som användes i ett första 

utkast visade sig ha stora begränsningar. Den nya 

versionen kan ibland kräva installation av en ny version 

av parser. 

• Svårt att få script på klientsidan att fungera. Här 

användes JavaScript för att hantera händelser, såsom 

knapptryckningar. Dessa var tvungna att läggas till som 

kommentarer i det stylesheet som ska används av en 

XML-sida. 

Som nämnts ovan finns inte så många eller inga fördelar alls 

med ASP-versionen som inte finns i XML-versionen. 

Fördelarna med XML-versionen återfinns nedan. 

Fördelar med XML-versionen 

• Datasträngen från komponenten är välstrukturerad. 

• Datasträngen kan kompletteras med nya taggar och 

taggarna kan kompletteras med nya attribut utan att 

XML-sidans stylesheet behöver ändras. Man kan dock 

45

46 


inte plocka bort taggar fritt eftersom en del behandlas 

speciellt. 

• Koden i XSL-filen är mycket strukturerad och 

kompletteringar kan lätt införas. 

• Utseendet på sidan som genereras kan lätt förändras 

eftersom koden i XSL-filen är välstrukturerad. 

Sammanfattning 

Med detta som grund var inte valet av teknik för 

webbgränssnittet svårt. För att få ett generellt gränssnitt 

kommer XML användas tillsammans med olika stylesheets 

(XSL-filer). På komponentsidan är valet av teknik redan gjort, 

men här behövs en noggrannare minneshantering för att slippa 

problemen med en alltför minneskrävande webbserver. 

I XML-versionen infördes även inloggning för att använda 

systemet. Detta kan man lägga över på IIS, men det gör 

hanteringen av de olika användarna för systemet mer 

komplicerad. Test med att spara data på webbservern från 

klienten genomfördes också. Denna funktionalitet ska kopplas 

ihop med användarautencieringen för att varje användare ska 

få tillgång till en egen projektmapp på servern och på så sätt 

skydda sina filer från obehöriga. Att spara filer på servern är 

inte ett krav på det slutliga systemet, men önskvärt eftersom 

man kanske vill justera sina värden vid ett senare tillfälle. 

Eftersom scriptspråk är relativt långsamt bör så mycket som 

möjligt av intelligensen och beräkningarna flyttas från 

scripten över till komponenten på serversidan. Exempel på 

detta är den användarautenciering som infördes i en av 

prototyperna enligt ovan. Kontrollen av användarens identitet 

görs via ett script som hämtar sin information från en databas 

med hjälp av gränssnittet ADODB. Om denna funktionalitet 

flyttas över till komponenten kan ODBC användas istället och 

scripten renodlas till att vara enkla metodanrop in i 

komponenten. 

Ännu en förbättring är att låta komponenten använda sig av 

olika XML-gränssnitt för att hantera datasträngarna som skall 

byggas upp. Detta har testats och komponenten blev då 

mycket mer minnessnål och koden mer strukturerad. 

Samtidigt testades att skicka färdiga XML-dokumentobjekt 

från komponenten till scripten som i sin tur skulle använda sig


av parsergränssnitt för att applicera olika stylesheets på dessa 

objekt. Resultatet av detta test var inte det önskade eftersom 

objekt inte kan skickas över gränssnitt som skall användas av 

ASP. Det går dock att genomföra detta om komponenten 

används av en applikation. Detta beror på att ASP inte stöder 

s.k. typkonvertering (type casting) till skillnad från 

applikationer. 

Vad som inte upptäcktes under utvecklingen av den första 

prototypen med XML var att tillsammans med XML-parsern 

kom även ActiveX-objekt för XML. Dessa gjorde det möjligt 

att returnera pekare till olika gränssnitt, exempelvis 

MSXML::IXMLDOMDocument. Det är alltså möjligt att 

slippa undan att returnera rena strängar från komponenten till 

ASP-scripten. Det här kommer att införas under 

implementationen av exempelsystemet (6 Implementation av 

exempelsystem). 

Det kan också behövas en noggrannare hantering av 

webbsessioner. Man kan i IIS ställa in sessioners varaktighet. 

En session är aktiv så länge webbsidor skickas från servern 

till klienten eller en viss tid efter det att ingen begäran av 

sidor kommer från klienten. Standardinställningen för detta är 

20 minuter. 

47

Implementation av exempelsystem 

6 Implementation av exempelsystem 

I detta kapitel beskrivs hur implementationen av ett 

exempelsystem fortlöpt. Som grund för implementationen 

ligger de erfarenheter och idéer som uppkom under 

prototyputveckligen. Det finns ingen formell 

kravspecifikation för systemet. 

6.1 Övergripande 

Enligt uppgiftsformuleringen för examensarbetet skall vissa 

delar av den funktionalitet som finns i det existerande 

systemet göras tillgängligt via ett webbgränssnitt. En lagom 

del av denna funktionalitet kan vara att göra beräkningar på 

färdiga mallar möjliga. Detta beskrivs nedan (6.1.1 

Funktionalitet i systemet). 

6.1.1 Funktionalitet i systemet 

Som nämndes ovan finns det ett antal mallar i det existerande 

systemet. Dessa mallar är till för att snabbt skapa en 

uppskattning av hur mycket material och arbete ett projekt 

kan kräva. Projekten kan vara allt från att riva hus till att lägga 

ner ett s.k. OPTO-nät i en innerstad/tätort. För alla dessa 

projekt finns olika mallar som i sin tur innehåller ett antal 

variabler. Exempel på sådana variabler är längd på kablar av 

olika typer, grävning/schaktning i terrängen, omskyltning av 

vägar under arbetet etc. Man kan sätta dessa variabler till 

olika värden och därefter utföra en beräkning av 

arbetskostnad, materialåtgång, tidsåtgång m.m. för projektet. 

Det är denna funktionalitet som eftersöks i webbgränssnittet 

för exempelsystemet. Som nämndes i uppgiftsformuleringen 

är implementationen av exempelsystemet till för att belysa 

problem och lösningar på dessa under komponentifieringen av 

ett existerande system. Det uppkommer dock fler problem 

beroende på begränsningar i scriptspråket som kommer att 

användas för att generera webbsidorna (se 4.3.3, Datatyper i 

ASP). 

Nedan listas önskvärd funktionalitet hos systemet: 

• Inloggning med identitetskontroll. 

• Listning av mallar som finns att tillgå. 

49

50 


• Inmatning av värden på variabler i mallarna. 

• Möjlighet att spara sina inmatade värden för senare 

justering. 

• Beräkna material- och arbetskostnad, material- och 

tidsåtgång för tillgängliga entreprenörer. 

• Möjlighet att spara resultaten av beräkningar på 

mallarna. 

• Hantera sina sparade mallvärden och resultat. 

Exempelvis ta bort, öppna och uppdatera värdena. 

Med dessa punkter som grund designades systemet enligt 

nedan (se 6.4, Design). 

6.2 Arbetsgång under utvecklingen 

Arbetsgången under utvecklingen följer gängse regler för 

sådant. Processen är uppdelad i tre huvuddelar: 

1. Design 

2. Implementation 

3. Testning 

Denna process är iterativ vilket innebär att vissa delar 

designas följt av implementation och testning. Processen 

börjar sedan om med design för ytterligare delar i systemet. 

Detta ställer stora krav på designen i de olika iterationerna 

eftersom man då måste göra denna så generell och 

strukturerad som möjligt för att ny, nästan godtycklig, 

funktionalitet ska kunna läggas till under senare iterationer. 

Innan designen kan påbörjas krävs givetvis en analysfas. 

Denna anses dock avslutad i och med att förstudieperioden 

avslutats, där analys i form av genomgång av det existerande 

systemet samt ett antal olika val gjorts (se 3, Förstudie). 

Eftersom inga tidigare erfarenheter för design och 

implementation av COM/ASP-kopplingar finns, förutom de 

från implementationen av prototyperna, påbörjas arbetet med 

att söka information om detta, framför allt på Internet.

Användardatabas 

Användardatabas 


6.3 Systemets uppbyggnad 

DOMDocument DOMDocument mm 

mm 

(gränssnitt) 

(gränssnitt) 

I figuren nedan (Figur 7) syns hur exempelsystemet är tänkt 

att se ut i stora drag. Detta ligger till grund för designen (se 

6.4, Design). För en utförlig beskrivning av Klipp se 4.3.2, 

Det existerande systemets uppbyggnad. 

KOMPONENT KOMPONENT 

WWW-server WWW-server WWW-server WWW server (IIS) 

(IIS) 

Komponenter 

Komponenter 

Klippdatabaser 

6.4 Design 

KLIPP 

KLIPP 

SERVER 

SERVER 

ASP 

ASP 

XML 

XML 

XSL 

XSL 

Figur 7. Exempelsystem översikt 

POST 

POST 

GET 

GET 

KLIENT 

KLIENT 

Webbläsare 

Webbläsare 

WWW-sidor 

WWW-sidor 

WWW-sidor 

WWW sidor 

I figuren ovan (Figur 7) syns hur systemet är tänkt att se ut i 

stora drag. Under designarbetet för komponenten är det 

speciellt viktigt att designa gränssnittet på ett bra sätt. Ett mål 

med detta är att hålla det så enkelt som möjligt. Eftersom 

komponenten är tänkt att användas från ASP-script kan den 

inte innehålla några s.k. callbacks, utan endast enkla 

metodanrop med in- och utparametrar av typen VARIANT (se 

4.3.3, Datatyper i ASP) eller pekare till gränssnitt som är 

kända i ASP-scripten. För att returnera en sådan pekare 

använder man IUnknown** (se A.3.1, Viktiga gränssnitt i 

COM/DCOM) från komponenten. För en detaljerad 

beskrivning av designen av komponenten se 6.4.1, 

Komponentdesign. 

51

52 


På webbserversidan finns ett antal mål att uppnå. Bland annat 

ska ASP-scripten innehålla så lite intelligens som möjligt. 

Dessa ska i stort sett endast innehålla ett anrop till 

komponenten och sedan ska resultatet, en XML-sträng, 

skrivas ut till HTTP-strömmen mot klienten. För en 

detaljerade beskrivning av designen av webbgränssnittet se 

6.4.2, Design av webbgränssnittet. 

6.4.1 Komponentdesign 

Det viktigaste med designen av komponenten är att få ett 

enkelt och effektivt gränssnitt mot klienterna som ska 

använda denna. Som nämnts tidigare bör gränssnittet endast 

innehålla enkla metodanrop utan callbacks, eftersom 

komponenten ska användas från ett antal ASP-script. Efter att 

ha granskat den önskvärda funktionaliteten hos systemet togs 

beslutet att använda två olika komponenter: 

• WebbKlipp 

• AnvandarHanterare 

Anledningen till den separata komponenten för 

användarhanteringen, AnvandarHanterare, är att det i 

framtiden kan bli aktuellt att sköta detta på något annat sätt. 

WebbKlipp är den komponent som gör det existerande 

systemet tillgängligt för webbgränssnittet genom att länka in 

de lib-filer som detta består av (se 3.1, Det existerande 

systemet). 

När man designar komponenter måste man göra ett val av 

vilken s.k. threading model (se A.6, Process/trådmodell 

(threading model)) komponenten ska använda. I det här fallet 

ska komponenterna användas från ASP-script och det 

rekommenderas då att man använder sig av s.k. apartment 

threading (se A.6.2, Apartment-threading). För att använda sig 

av denna modell används ett direktiv som läggs i filen 

stdafx.h enligt: 

#define _ATL_APARTMENT_THREADED 

Innan valet av threading model görs ska man välja vilken typ 

av server som ska användas. I det här fallet valdes en DLLserver 

(se A.2, Arkitekturen hos COM/DCOM) med stöd för 

MFC, Microsoft Foundation Class Library. Detta val gör man 

i ATL COM AppWizard i Visual C++. 

Ovanstående val gäller för båda komponenterna i systemet.

WebbKlipp 


Den önskvärda funktionaliteten för systemet kräver sex 

gränssnittsmetoder: 

• HamtaMallNamnXML – Hämta en lista med namnen 

på alla tillgängliga mallar. 

• HamtaVariablerXML – Hämta en lista med variabler 

för en given mall. 

• BeraknaXML – Utför beräkningen. 

• SparaDataXML – Sparar mallar och resultat på servern. 

• HamtaSparadDataXML – Hämtar sparade mallar och 

resultat från servern. 

I tabellen nedan (Tabell 1) återges metoderna för gränssnittet. 

Där syns hur parametrarna definieras, med givna attribut. 

Dessa attribut kan vara: 

• in – parametern är en ren in-parameter. 

• out – parametern är en ut-parameter, till vilken man kan 

tilldela ett värde som kan användas av klienten. 

• retval – parametern används som resultat av 

metodanropet. 

Gränssnittsmetoder 

HamtaMallNamnXML([out, retval] IUnknown** pUnkXMLDoc) 

Parametrar: 

pUnkXMLDoc En pekare till ett IXMLDOMDocument som innehåller 

listan med namnen på tillgängliga mallar. 

HamtaVariablerXML([in] long lMId, [in] long lMRef, 

[out, retval] IUnknown** pUnkXMLDoc) 

Parametrar: 

lMId Id för den mall vars variabler som skall hämtas. 

lMRef Referensnummer för den mall vars variabler som skall 

hämtas . 


listan med variabler för mallen. 

BeraknaXML([in] VARIANT* bstrInXMLDoc, [in] VARIANT* bstrProjNamn, 


Parametrar: 

bstrInXMLDoc Sträng med värden på mallens variabler, som skall 

användas vid beräkningen. Skulle felaktiga värden matas 

53

54 


in kommer Klipp att använda default-värden på dessa. 

bstrProjNamn Namnet på projektet (mallen). 


resultatet av beräkningen, arbetskostnader mm. 

SparaDataXML([in]VARIANT* bstrPath, [in] VARIANT* bstrFilNamn, 

[in] int nReplace, [in] VARIANT* bstrFilData, 


Parametrar: 

bstrPath Sökvägen där filen ska sparas på servern. 

bstrFilNamn Namnet på filen. 

nReplace Ska existerande fil skrivas över? 

bstrFilData XML-strängen som ska skrivas till filen. 


information om hur sparningen gick. 

HamtaSparadData([in] VARIANT* bstrPath, 


Parametrar: 

bstrPath Sökvägen inklusive filnamnet på filen som ska hämtas. 


XML-dokumentet i filen. 

Tabell 1. Gränssnittsmetoder för IMallHantering i WebbKlipp. 

Alla metoder i gränssnittet returnerar HRESULT, vilket är ett 

heltal som innehåller information om hur exekveringen av en 

metod gick. Om ett metodanrop misslyckades innehåller 

HRESULT information om vad som gick fel, annars 

innehåller det konstanten S_OK. 

För att hålla implementationsklassen för gränssnittet enkelt 

kommer den verkliga funktionaliteten i gränssnittet 

abstraheras till underliggande klasser. Implementationsklassen 

kommer att heta CMallHantering och innehålla metodanrop 

ner i en underliggande klass som heter CXMLBuilder. I 

CXMLBuilder byggs XML-objektet upp och returneras till 

implementationsklassen. För att utnyttja 

IXMLDOMDocument m.m. i CXMLBuilder behöver denna 

klass importera en DLL-fil, msxml.dll. Denna import kommer 

att göras i filen stdafx.h, vilket gör gränssnitten åtkomliga för 

alla klasser i komponenten. Även CMallHantering behöver 

msxml.dll för att kunna tilldela utparametrarna pekarvärden 

till IXMLDOMDocument. 

Utseendet på CXMLBuilder kommer att vara i stort sett 

samma som gränssnittets och även implementationsklassen


CMallHanterings utseende. Därför återges ingen tabell för 

metoderna i denna klassen. 

För att göra även CXMLBuilder så ren som möjligt behövs en 

hjälpklass, som bland annat innehåller metoder för att skapa 

noder i XML-dokumentet samt sätta och hämta attribut för 

noderna. Klassen heter CDOMHelper och innehåller följande 

metoder: 

Metoder i CDOMHelper 

CDOMHelper() 

Parameterlös konstruktor Inga medlemsvariabler finns, därför behövs inga 

initieringar. 

~CDOMHelper() 

Destruktor. 

MSXML::IXMLDOMNode* CreateDOMNode( 

MSXML::IXMLDOMDocument* pDoc, 

int type, BSTR bstrName) 

Skapar en tom IXMLNode som kan läggas till i XML-dokumentet. 

Parametrar: 

pDoc Pekare till det XML-dokumentobjekt som ska innehålla 

den nya noden. 

type Konstant heltal som talar om vilken typ av nod som ska 

skapas. Oftast MSXML::NODE_ELEMENT. 

bstrName Namnet på noden som ska skapas. 

HRESULT SetAttribute(MSXML::IXMLDOMNode* pNode, int type, 

BSTR bName, VARIANT val) 

Sätter attribut med namn och typ till ett värde. 

Parametrar: 

pNode Noden som ska få ett attribut. 

type Attributets typ. Oftast VT_BSTR. 

bName Attributnamnet. 

val Attributets värde. 

BSTR GetAttribute(MSXML::IXMLDOMNode* pNode, BSTR attrName) 

Hämtar givet attribut för en nod. Returnerar detta som en BSTR. 

Parametrar: 

pNode Noden som innehåller attributet. 

attrName Namnet på attributet som ska hämtas. 

Tabell 2. Metoder för hjälpklassen CDOMHelper. 

55

56 

Klipp 

Klipp 

MB3Db.lib MB3Db.lib MB3Db. lib 

MB3PrDb.lib 

MB3PrDb.lib 

MB3PrDb. lib 


Anledningen till att lägga ut metoderna i en separat klass är att 

dessa används ofta och i framtiden kan det tänkas behövas 

flera sådana. 

Ovan givna design ger ett utseende på WebbKlippkomponenten 

enligt figuren nedan (Figur 8). 

MB3Model.lib 

MB3Model.lib 

MB3Model. lib 

MB3Util.lib MB3Util.lib MB3Util. lib 

Figur 8. Struktur på WebbKlipp.IMallHantering. 

Efter implementationen kommer dokumentation genereras 

med hjälp av verktyget doxygen [23]. Dokumentationen 

kommer att finnas tillgänglig i HTML-format 

(QWERTYNISSE!!! Referens till detta). 

AnvandarHanterare 

IDispatch 

IDispatch 

CMallHantering 

CMallHantering 

CXMLBuilder 

CXMLBuilder 

CDOMHelper 

CDOMHelper 

msxml.dll msxml.dll msxml dll 

IMallHantering 

IMallHantering 

Eftersom detta är ett testsystem kommer inte 

användaridentifieringen var så avancerad. Användarnamn och 

lösenord kontrolleras mot en databas, Access, och om dessa 

angivits korrekt används cookies för att ASP-scripten ska


komma ihåg att användaren är korrekt inloggad. I databasen 

sparas även information om var på servern en användares 

sparade data ligger. Gränssnittet i den här komponenten, 

IAuth, innehåller endast en metod, LoggaIn enligt tabellen 

nedan. 

Gränssnittsmetoder 

LoggaIn([in] VARIANT* bstrSession, [in] VARIANT* bstrUserId, 

[in] VARIANT* bstrPassWd, [out] VARIANT* bstrPath, 

[out] VARIANT* bstrKey) 

Tar användarnamn och lösenord från ett inloggningsförsök, kontrollerar dessa mot 

databasen och lagrar användarens ”hembibliotek” och en nyckel i utparatmetrarna. 

Parametrar: 

bstrSession Förberett för att ta ett sessions-id och generera en nyckel 

för inloggningen. 

bstrUserId Användarnamnet. 

bstrPassWd Lösenordet. 

bstrPath Användarens hembibliotek. 

bstrKey Resultat från inloggningen. 

Tabell 3. Gränssnittsmetoder för IAuth i AvandarHanterare. 

Implementationsklassen för IAuth använder sig av en 

hjälpklass som hanterar all access till databasen. Hjälpklassen 

heter DBClass och ser ut enligt tabellerna nedan. 

Medlemsvariabler i DBClass 

BSTR m_bstrLoginRes 

Resultatet av ett inloggningsförsök. 

BSTR m_bstrProjPath 

Sökvägen till en användares ”hembibliotek” på servern om inloggningen var 

korrekt. 

Metoder i DBClass 

Tabell 4. Medlemsvariabler i DBClass. 

void LoggaIn(BSTR bstrSession, BSTR bstrUserId, BSTR bstrPassWd) 

Kontrollerar användarnamn och lösenord mot databasen och sparar sökväg och resultat 

i medlemsvariablerna. 

Parametrar: 

bstrSession ID för webbsessionen. 

bstrUserId Användarnamnet. 

bstrPassWd Lösenordet. 

57

58 


Tabell 5. Metoder i klassen DBClass. 

Strukturen på komponenten och gränssnittet ser då ut enligt 

figuren nedan (Figur 9). 

CAuth 

CAuth 

IDispatch 

IDispatch 

CDbClass 

CDbClass 

sql.h sql.h sql.h sql .h sqlext.h sqlext.h sqlext.h sqlext .h 

Figur 9. Struktur på AnvandarHanterare.IAuth. 

Allmänna kommentarer 

Access Access (users (users (users ( users.mdb users.mdb users.mdb mdb) 

Denna design ger det ungefärliga utseendet på 

komponentsidan i figuren ovan (Figur 7). 

IAuth 

IAuth


6.4.2 Design av webbgränssnittet 

Det finns ett flertal saker att tänka på när man ska skapa en 

design för ett webbgränssnitt. Detta märktes under 

prototyputvecklingen. 

Det största problemet då var att webbläsarna som användes 

för att utvärdera gränssnitten lagrade vissa sidor i sin cache. 

Detta medförde att de sidor som frekvent ändrar utseende inte 

alltid uppdaterades korrekt. Detta kan dock styras till viss del 

genom att konfigurera webbservern, Microsoft IIS [21]. Man 

kan tala om att sidorna i ett virtuellt bibliotek på servern blir 

ogiltiga direkt, vilket förhindrar att de hamnar i cachen. 

Internet Explorer ignorerar oftast sådana inställningar 

eftersom man kanske vill stega bakåt med hjälp av bakåtknappen 

i läsaren utan att ladda om sidan från servern. Detta 

ger problem när man vill använda stylesheets för att formatera 

XML-strängen eftersom dessa inte alltid används när en sida 

hämtas från cachen. 

En annan viktig detalj är att underlätta vidareutveckling av 

gränssnittet. Detta gäller för all design inom alla områden, 

men är speciellt viktigt i ett webbgränssnitt eftersom detta 

uppdateras relativt ofta. 

I det här systemet valdes att strukturera upp olika filtyper i 

olika mappar på servern. I exempelsystemet finns framför allt 

fem typer: 

• ASP-script 

• XSL-filer (stylesheets) 

• HTML-filer 

• Användardatabas 

• Bilder 

Till dessa kommer även användarnas ”hembibliotek”, en 

blandat-mapp som innehåller förklarande presentationer i 

PowerPoint [24] samt en mapp som innehåller en uppdatering 

av XML-parsern. Detta resulterar i följande katalogstruktur på 

servern. 

59

60 

www-root www-root www-root www root 

WebbKlipp 

WebbKlipp 


Figur 10. Katalogstruktur på webbservern 

Med denna katalogstrukturen är det lätt för de som ska 

vidareutveckla gränssnittet att navigera och hitta rätt filer. 

Nedan beskrivs lite mer utförligt vad de olika katalogerna 

innehåller. 

www-root 

Roten för webbservern, vilket är den mapp man kommer till 

om man anger adressen http://datornamn_eller_ip/. Man kan 

på webbservern specificera virtuella bibliotek, i det här fallet 

är WebbKlipp ett sådant. 

WebbKlipp 

Detta är roten för webbgränssnittet och innehåller endast en fil 

med namnet login.html, samt biblioteken beskrivna nedan. 

ASP 

ASP 

ASP 

HTML 

HTML 

IMAGES 

IMAGES 

XSL 

XSL 

MSXML 

MSXML 

Mappen innehåller alla ASP-script. Dessa filer hör ofta ihop 

med stylesheet-filer i mappen XSL. Scripten ska vara så enkla 

som möjligt och i stort sett endast innehålla enkla metodanrop 

till komponenterna och sedan skriva ut det, av komponenten, 

genererade XML-dokumentet. 

ASP – INC 

INC 

INC 

*.asp 

*.asp 

*.htm/html 

*.htm/html 

*.inc *.inc *.inc *. inc 

*.jpg/gif *.jpg/gif *.jpg/gif *.jpg/ gif/bmp gif/bmp gif/bmp bmp mm. 

mm. 

*.xsl *.xsl *.xsl *. xsl 

xmlinst.exe xmlinst.exe xmlinst.exe xmlinst exe 

xmlinst.exe xmlinst.exe xmlinst.exe xmlinst exe.ReadMe 

exe.ReadMe 

exe.ReadMe ReadMe.txt ReadMe.txt ReadMe.txt txt 

db db 

users.mdb users.mdb users.mdb users mdb 

projects 

projects 

anv1 

anv1 

anv2 

anv2 

anv3 

anv3 

anv4 

anv4 

Innehåller inkluderingsfiler som används frekvent från ASPscripten. 

Exempel på sådant är ett script som kontrollerar om 

*.xml *.xml *.xml *. xml 



*.xml *.xml *.xml *. xml


användaren är korrekt inloggad vid varje förfrågan till 

webbservern. Inloggningsinformationen ligger sparad i 

cookies. 

HTML 

Mappen innehåller de rena HTML-filerna som ingår i 

gränssnittet. 

IMAGES 

Katalogen innehåller alla bilder som ingår i gränssnittet. 

XSL 

Innehåller de stylesheets som genererar utseendet på sidorna 

utifrån uppsatta regler och XML-dokumenten från 

komponenten. 

MSXML 

Innehåller en uppdatering av XML-parsern som behövs för att 

sidorna ska genereras korrekt. Uppdateringen kommer från 

Microsoft. 

db, projects 

Katalogerna är till för användardatabasen (db) och 

användarnas hembibliotek (projects). 

6.5 Implementation 

Implementationen av systemet var relativt enkel eftersom 

prototyperna utvecklats tidigare. Större delen av källkoden, 

både på komponentsidan och på webbgränssnittssidan, kunde 

återanvändas, efter vissa justeringar och förbättringar. För lite 

mer ingående information om implementationen av 

komponenterna och webbgränssnittet, se nedan (6.5.1, 

Komponenterna, och 6.5.2, Webbgränssnittet). 

6.5.1 Komponenterna 

Som nämnts ovan (se 6.4.1, Komponentdesign) skapades två 

komponenter, WebbKlipp och AnvandarHanterare. Man 

skulle kunna lagt dess funktionalitet i samma komponent med 

två olika gränssnitt, men användarautencieringen ska kunna 

bytas ut utan att stora förändringar behöver göras. Detta löser 

man enklast genom att lägga WebbKlipp- och 

61

62 


AnvandarHanteraredelarna i två helt skilda komponenter. 

Eftersom prototyperna som utvecklats på komponentsidan är 

relativt genomarbetade så är grundutseendet ungefär samma 

på komponenterna i exempelsystemet. Designen av dessa är 

enkel och därför återges ingen detaljerad 

implementationsbeskrivning. För en detaljerad beskrivning av 

klasserna som ingår finns dokumentation av dessa i form av 

HTML-sidor genererade med hjälp av verktyget doxygen 

[23]. 

För att få komponenterna att returnera en pekare till ett 

IXMLDOMDocument krävdes en ganska komplicerad 

konstruktion. Komponenterna kan bara använda sig av 

VARIANT-strukturer för att transportera data genom 

gränssnittet. I VARIANT ingår, som nämnts tidigare, de flesta 

grundläggande datatyperna, men även pekare till IUnknowngränssnittet. 

Eftersom alla gränssnitt ärver egenskaper och 

metoder från IUnknown kan detta gränssnitt användas för att 

transportera andra datastrukturer genom gränssnittet för en 

komponent. I fallet med IXMLDOMDocument genomfördes 

detta med hjälp av nedanstående konstruktion (Listning 5). 

STDMETHODIMP CMallHantering::HamtaMallNamnXML(IUnknown 

**pUnkXMLDoc) 

{ 

} 

AFX_MANAGE_STATE(AfxGetStaticModuleState()) 

// TODO: Add your implementation code here 

MSXML::IXMLDOMDocument *pDoc = NULL; 

CXMLBuilder xmlBuilder; 

pDoc = xmlBuilder.HamtaMallNamn(); 

*pUnkXMLDoc = (IUnknown*)pDoc; 

return S_OK; 

Listning 5. Exempel för att transportera IXMLDOMDocument genom 

gränssnittet. 

I listningen ovan (Listning 5) är tre detaljer markerade med 

fet stil. Det är de som gör det möjligt att skicka pekare till 

XML-objekt genom gränssnittet. pDoc byggs upp inne i


hjälpklassen CXMLBuilder. Denna pekare typomvandlas 

sedan till en IUnknown-pekare, som kan skickas genom 

gränssnittet till ASP-scriptet. Detta förfarande användes på 

alla ställen där ett XML-dokument skulle returneras till 

klienten. 

Egenskapen hos gränssnitten som används ovan kan utnyttjas 

till att transportera komplicerade objekt genom gränssnitten 

för komponenter. Man kan exempelvis konstruera egna 

gränssnitt och sedan typomvandla dessa till IUnknown innan 

man skickar dem till klienten. I det här systemet krävdes dock 

inte detta, men möjligheten är intressant och kraftfull. 

En detalj som fattades i prototyperna var felhantering. Detta 

lades till i komponenterna för exempelsystemet genom att ett 

XML-dokument innehållande felinformation genererades och 

skickades tillbaka till klienten om något inte skulle gå som 

planerat. På så sätt kan administratorn för systemet meddelas 

och felinformationen kan användas för att spåra felkällan. 

6.5.2 Webbgränssnittet 

Det största arbetet under implementationen av 

webbgränssnittet bestod av definitionen av stylesheets, XSLfilerna, 

som genererar utseendet på gränssnittet. Även här 

saknades felhantering i prototyperna. Detta infördes i 

exempelsystemet genom att felinformationen från 

komponenten presenteras för användaren som i sin tur 

uppmanas att kontakta administratorn för systemet. Utöver 

detta lämnas felhanteringen till XML-parsern på klientsidan. 

Samma sak gäller för ASP-scripten. Dessa innehåller i stort 

sett ingen intelligens utan skriver endast ut det XMLdokument 

som genereras av komponenten. Webbservern ger 

användaren information om fel skulle uppkomma. Denna 

information är ingående och räcker gått och väl för att ge en 

tillfredsställande information om felets typ och orsak. 

Nedan ges ett exempel på ASP-script för att hämta och skriva 

ut det XML-dokument som genereras när man vill lista alla 

tillgängliga mallar i systemet (Listning 6). 

 

63

64 


 

 

 

Set so = Server.CreateObject("WebbKlipp.MallHantering") 

Set xmlObj = Server.CreateObject("Msxml2.DOMDocument") 

xmlObj.load(so.HamtaMallNamnXML) 

Response.write(xmlObj.xml) 

Set so = Nothing 

Set xmlObj = Nothing 

End if 

Listning 6. Exempel på ett ASP-script, mall-lista.asp. 

Överst i listningen ovan (Listning 6) syns exempel på en 

inkludering av en fil från INC-katalogen i ASP-katalogen. Vi 

ser också hur ASP-scriptet innehåller en instans av 

Msxml2.DOMDocument för att kunna hantera pekaren till ett 

IXMLDOMDocument genererat av komponenten, 

WebbKlipp.IMallHantering. Liknande konstruktioner kan 

användas i JavaScript på klientsidan för att hantera XMLdokumenten. 

Då används ett ActiveX-objekt, 

Microsoft.XMLDOM, som skapas enligt nedan: 

var xmlDoc = new ActiveXObject("Microsoft.XMLDOM"); 

Detta objekt och det med liknande namn i ASP-scriptet ovan 

(Listning 6), Msxml2.DOMDocument, är av samma typ och 

används på samma sätt. Användandet av ActiveX-objektet 

enligt ovan löste ett problem som fanns hos prototyperna. 

Vissa operationer i webbgränssnittet kräver att man går in och 

ändrar data i XML-dokumentet. Man kan göra detta genom att 

ändra själva strängen som bygger upp dokumentet. Det ska 

dock inte vara tillåtet, men lyckades i de flesta fallen ändå. 

Vad som ibland hände var att man fick upp ett felmeddelande 

om att man försökte ändra ett skrivskyddat objekt. För att få 

bort detta beteende infördes istället ActiveX-objektet, enligt 

ovan, och man manipulerade då XML-dokumentet genom att 

jobba med XML-objektet istället för direkt på datasträngen.


6.6 Resultat av design/implementationen 

Ett av flera mål med design- och implementationsarbete är ett 

stabilt, snabbt och effektivt system med lättläst och 

strukturerad källkod. Lyckas man med det är systemet lätt att 

underhålla och vidareutveckla. Dessa mål kan dock vara svåra 

att uppnå, framför allt i system med webbgränssnitt som 

innehåller script. Detta lyckades dock genom att hålla ASPscripten 

så korta som möjligt. Det största arbetet på 

webbgränssnittssidan var arbetet med stylesheets, XSLfilerna. 

Dessa kom att innehålla en hel del JavaScript för att 

bland annat uppdatera XML-dokumentet som visas på sidan 

innan detta ska skickas till servern för lagring. Det som ändå 

gör denna källkod strukturerad och lättarbetad är att XML i 

sig kräver struktur när det gäller start- och sluttaggar i koden. 

Om ren HTML skulle användas är det svårt att hålla 

strukturen eftersom HTML inte kräver sluttaggar för att ändå 

generera önskat resultat. 

6.7 Testning 

Om man skulle sätta ett formellt namn på testningsmetoden 

för komponenterna så ligger svartlåde-testning närmast till 

hands. 

Det har dock inte genomförts någon formell testning av 

systemet, med användarfall, testprotokoll m.m. Däremot 

implementerades en testapplikation som använde sig av 

komponenterna i systemet. Med hjälp av denna applikation 

kunde utresultaten från komponenterna kontrolleras så att 

dessa överensstämde med det förväntade. Genom att använda 

sig av en sådan applikation kunde minnesläckage m.m. lättare 

upptäckas eftersom man då kunde välja att köra i debugläge 

och även debugga in i komponenterna (DLL-filerna). 

Testningen var sådan att när en gränssnittsmetod 

implementerats så kollades denna med hjälp av 

testapplikationen innan den testades via ASP-scriptet i 

webbgränssnittet. Det är mycket svårt att upptäcka fel i en 

komponent som används via ASP-script. 

För att testa systemet under normal användning 

demonstrerades det för ansvariga för det existerande systemet 

på Telia. Demonstrationen fungerade som en introduktion till 

användning av systemet och sedan gjordes det tillgängligt för 

65

66 


användning inom Telia. För reaktioner och kommentarer från 

användare på Telia, se 7.2, Reaktioner från kund och 

testpersoner. Från denna testning kunde även webbserverns 

beteende kontrolleras under normal användning. Det bör dock 

nämnas att systemet i framtiden kan komma att användas av 

fler personer än de som just nu fått tillgång till det. 

Testanvändningen är tänkt att ge en fingervisning om 

systemets prestanda och stabilitet.

Utvärdering och förbättringsförslag 

7 Utvärdering och förbättringsförslag 

I det här kapitlet återfinns reaktioner och tankar från kunden 

samt en del förslag på förbättringar. Bland annat har DCOM 

studerats noggrannare än tidigare under arbetet och ett par 

förslag på systemuppbyggnad med DCOM och ActiveX som 

komponentteknik har tagits fram. 

7.1 Utvärdering 

Utvärderingen av exempelsystemet bör koncentreras på att 

utvärdera själva komponenten och inte det webbgränssnitt 

som implementerats. Visserligen är det så att en bra 

fungerande komponent i det här fallet ger en bra grund för att 

kunna utveckla ett avancerat, användarvänligt och effektivt 

webbgränssnitt. 

7.1.1 Genomförande 

Att utvärdera en komponent av den här typen, som utvecklats 

för exempelsystemet, kräver en applikation eller motsvarande 

som använder sig av komponenten. Denna applikation kan 

exempelvis simulera många simultana användare av 

komponenten. Om komponenten ska användas via en 

webbserver kan man använda sig av en s.k. Web Stress Tool. 

Ett sådant verktyg gör det möjligt att simulera många 

användare på en webbserver. Man kan efter en körning få en 

rapport innehållande svarstider och minneåtgång för 

serverapplikationen m.m. Ännu intressantare blir det om man 

under en körning bevakar hur webbservern reagerar på hög 

belastning. 

Verktyget som användes för att belasta komponenten via 

webbgränssnittet var Microsoft Web Application Stress Tool 

1.1 [26], som kan laddas ned gratis från hemsidan. 

Testanvändare har även fått använda systemet och resultatet 

blev förslag på förbättringar. Då uppkommer dock problemet 

med att utvärderingen inte koncentreras på själva 

komponenten utan mer på webbgränssnittet. Resultaten från 

detta återges i 7.2, Reaktioner från kund och testpersoner. 

67

68 

7.1.2 Resultat 


Resultaten från Microsoft Web Application Stress Tool 1.1 

[26] granskades för att se hur användningen av komponenten 

via webbgränssnittet gått. Alla delar av komponenten kunde 

inte testas eftersom dessa kräver inmatning av värden i vissa 

fält, vilket inte stöds av utvärderingsverktyget. 

Verktyget konfigurerades till att simulera 100 simultana 

användare under tre minuter. Under körningen lyckades alla 

accesser till komponenten och mängden data från 

komponenten stämde överens med det förväntade. 100 

simultana användare är en hög belastning under de 

förhållande som komponenten är avsedd att användas. 

Minnesåtgången för komponenten var nästan konstant, efter 

det att alla 100 användarna börjat använda den. Vissa 

variationer fanns dock, men det uppkom aldrig någon onormal 

stegring under körningen. Detta tolkas som ett lyckat resultat. 

Här följer en kort tolkning av ett resultat för en körning: 

Under de tre minuter körningen varade gjordes 141 anrop till 

komponenten, alla lyckades. Detta innebär att ca 1 

anrop/sekund vilket är ett bra resultat för användning via ett 

ASP-script. Under körningen genererades 1 808,49 kB data 

(ca 1,77 MB) av komponenten där varje anrop generade 

12 893 B (ca 12,59 kB). Av detta kan slutsatsen dras att vid 

100 simultana användare kan ungefär en webbsida per 

sekund genereras. Detta är ett lyckat resultat. 

7.2 Reaktioner från kund och testpersoner 

Som nämnts ovan gjordes en demonstration av systemet för 

ansvariga för det existerande systemet, Klipp. Reaktionerna 

efter demonstrationen var positiva och WebbKlipp gjordes 

tillgängligt för anställda på Telia. Det som krävs för att 

använda det är ett användarkonto, som kan läggas till och tas 

bort med hjälp av en administrationsdel för systemet. 

Från de som testar systemet kommer reaktioner och förslag på 

förbättringar. Det som inte gör detta idealt är att en 

slutanvändare inriktar sig i huvudsak på hur 

användargränssnittet ser ut, i det här fallet webbgränssnittet. 

Det är inte detta som är huvuduppgiften i examensarbetet. 

Detta medför att för att skaffa sig en bra bild över hur


systemet fungerar måste loggfiler, minneshanteringsstatistik 

m.m. användas och tolkas. Hittills har data från dessa källor 

inte innehållit några överraskningar och framför allt inga 

systemkrascher. Testpersonerna på Telia har dock inte 

belastat systemet så tungt som det i framtiden kan tänkas göra, 

men en viss tendens syns i alla fall. 

För att nämna några av de förbättringsförslag som kommit 

från Telia så rör det sig framför allt om det synliga grafiska 

gränssnittet och då att detta ska se enhetligt ut med resten av 

Telias webbsidor. För förbättringsförslag som rör själva 

komponenterna, se 7.3, Förbättringsförslag. 

7.3 Förbättringsförslag 

Det som är intressant för examensarbetet är själva 

komponentifieringen, inte användbarheten hos 

användargränssnitt. Det är svårt att få testen, genom bara 

normal användning av systemet, att avspegla komponenternas 

effektivitet. Trots detta har ett antal förslag på annan 

systemuppbyggnad tagits fram. I dessa förslag har DCOM 

introducerats eftersom vissa beräkningar och databasaccesser 

kan vara betungande för webbservermaskinen. Det kan alltså 

vara önskvärt att lägga ut dessa på andra maskiner i nätverket. 

I avsnittet 7.4, Alternativa tekniker (DCOM), nedan ges två 

förslag på sådana lösningar. Tekniken DCOM har testats 

genom att en klient och en server utvecklats, dock inte enligt 

förslagen i avsnittet nedan. Klienten är en fristående 

applikation och servern existerar endast på en maskin, alltså 

ett system utan en s.k. referral component (se A.7, 

Arbetsfördelningsmodeller för DCOM). Det som är verkligen 

intressant med det här systemet är att DCOM-servern 

använder sig av komponenten som används från 

webbgränssnittet för att kommunicera med det befintliga 

systemet. DCOM-servern fungerar alltså som en 

inkapslingskomponent för att möjliggöra kommunikation 

enligt DCOM. 

För mer ingående beskrivning av DCOM-systemen, se 7.4, 

Alternativa tekniker (DCOM), nedan. 

69

70 


7.4 Alternativa tekniker (DCOM) 

I 7.1.2, Resultat, syns att systemet utan större problem klarar 

av 100 simultana användare, i alla fall om inte de tyngsta 

operationerna utförs. Exempel på tung operation är när själva 

beräkningen av material- och arbetskostnader m.m. ska 

utföras. Det som ligger närmast till hands för att lätta på 

bördan för komponenten under denna operation, är att man 

skapar ett antal distribuerade komponenter som ligger på 

andra maskiner (se A.7, Arbetsfördelningsmodeller för 

DCOM). Nackdelen med denna lösning är att man behöver 

installera komponenterna på varje maskin som ska verka som 

beräkningsdator. I fallet med komponentifiering av Klipp 

medför detta också att de databaser som ingår i systemet 

måste ligga på alla dessa maskiner. Det introducerar alltså 

problem när uppdateringar av systemet sker. 

I appendix A, COM/DCOM, återfinns mer information om 

DCOM. Detta appendix innehåller visserligen mest 

information om COM, men DCOM är uppbyggt på ungefär 

samma sätt och stöder i stort sett samma funktionalitet. 

7.4.1 Exempelsystemet (DCOM-version) 

Målet med detta system är att distribuera tunga operationer. 

Det är inte aktuellt som exempelsystemet ser ut idag, men om 

ytterligare funktionalitet skulle läggas till kan belastningen på 

webbservermaskinen bli för stor. Om systemet skulle bli 

distribuerat är det inte så känsligt för ökat användarantal. 

Eftersom systemet är tänkt att användas via ett webbgränssnitt 

är det inte lätt att gruppera användarna. Alltså passar 

dynamisk arbetsfördelning bäst. På webbserverdatorn behövs 

en Referral Component för att fördela arbetet. Den här 

komponenten väljer den, för tillfället, minst belastade servern 

och returnerar en uppkoppling till klienten. Klienten i det här 

fallet är det ASP-script som innehåller metodanrop till en 

komponent. ASP-scriptet aktiveras på vanligt sätt genom att 

en webbsida begärs från webbservern. De distribuerade 

serverkomponenterna fungerar på i stort samma sätt som 

COM-versionen beskriven ovan (se 6, Implementation av 

exempelsystem). Varje serverkomponent har tillgång till det 

existerande systemet genom inlänkade lib-filer samt 

databaserna. Databaserna måste, som nämnts tidigare, finnas

Klient 1 

Klient 2 


på varje server. Systemet får då utseendet enligt nedan (Figur 

11). 

WWW-server 

1 2 

5 

RefKomp 

ASP 

XSL 

Figur 11. Exempelsystemet (DCOM-version) 

Här syns hur ett metodanrop kan gå till: 

x antal komponenter på 

x antal maskiner 

1. En användare begär en webbsida (ASP-script) från 

webbservern. 

2. Scriptet kontaktar en Referral Component, RefKomp, 

som kontrollerar vilken av maskinerna med 

serverkomponenter som är minst belastad. 

3. RefKomp hittar en server, belastad till 25%, och skapar 

en koppling mot denna. 

4. RefKomp returnerar kopplingen till klienten (ASPscriptet 

i det här fallet) som anropar en metod i 

serverkomponenten. 

5. Scriptet returnerar ett formaterat resultat till webbsidan. 

Efter det att RefKomp returnerat kopplingen mot servern till 

klienten är den helt frikopplad och direkt beredd att ta emot 

fler förfrågningar. Man avlastar alltså webbservermaskinen 

markant. 

3 

4 

45% 

25% 

60% 

85% 

50% 

Klipp 

Klipp 

Klipp 

Klipp 

Klipp 

71

72 


Viktigt att ta med i beräkningarna om man ska distribuera ett 

system eller ej är hur nätverket, i vilket systemet ska 

användas, ser ut. Är detta långsamt eller om webbservern inte 

kan ligga nära komponentservermaskinerna kan det hända att 

systemet blir långsamt och tungarbetat. Det blir också en stor 

ökning i trafiken över nätverket vilket kan göra systemet 

olämpligt att distribuera. 

7.4.2 Exempelsystem (ActiveX/DCOM) 

Ytterligare en variant på uppbyggnaden av exempelsystemet 

har tagits fram. I den här versionen har det rena 

webbgränssnittet bytts ut mot en ActiveX-komponent som 

aktiveras via en webbsida. Fördelen med det här är att ett 

mycket mer avancerat användargränssnitt kan användas, 

vilket faktiskt kan byggas upp så att det blir identiskt med det 

existerande systemets utseende. Det krävs dock att varje klient 

som ska använda systemet installerar denna ActiveXkomponent 

lokalt. Detta kan dock skötas med automatik 

genom att komponenten laddas ned från servern om denna 

inte är installerad och registrerad på klienten. Det enda 

ActiveX-komponenten kommer att innehålla är då ett grafiskt 

användargränssnitt och anrop till en distribuerad komponent 

som använder sig av det existerande systemet på samma sätt 

som i det implementerade exempelsystemet (se 6, 

Implementation av exempelsystem). 

Med detta som grund kommer ActiveX/DCOM-versionen att 

se ut enligt nedan (Figur 12).

Klient 1 

ActiveX 

Klient 2 

ActiveX 


1 

2 

3 

5 

WWW-server 

HTML 

ActiveX 

RefKomp 

Figur 12. ActiveX/DCOM-version av exempelsytemet 

Scenariot ser ut som följer: 

1. En klient går in på adressen för en webbsida. 

x antal komponenter på 

x antal maskiner 

2. Webbsidan innehåller ett ActiveX-objekt som 

aktiveras. Komponenten laddas ned och installeras om 

inte klienten redan gjort detta. 

3. Vid aktiveringen av ActiveX-komponenten kontaktar 

denna en distribuerad Referral Component, RefKomp. 

4. RefKomp skapar en uppkoppling mot den distribuerade 

komponenten som är minst belastad och returnerar 

denna koppling till ActiveX-objektet på klienten. 

5. Klienten och den distribuerade komponenten utbyter 

tjänster med varandra. 

Valet av distribuerad komponent utförs alltså av RefKomp 

och valet baseras på olika kriterier, i det här fallet minst 

arbetsbelastning på de distribuerade komponenterna. 

Klipp 

Klipp 

Klipp 

Klipp 

Klipp 

Vissa tester har genomförts för att få nedladdning och 

installation av ActiveX-komponenten att fungera på ett bra 

sätt. För att få det att fungera ordentligt krävs dock att man får 

4 

45% 

35% 

60% 

25% 

50% 

73

74 


sin komponent signerad, vilket innebär att den måste uppfylla 

vissa krav.


8 Slutsatser, resultat och erfarenheter 

I det här avsnittet presenteras en del av de slutsatser som kan 

dras av arbetet, framför allt när det gäller förutsättningarna för 

ett system att kunna användas som komponent. En del av de 

erfarenheter och lärdomar som erhållits under arbetes gång 

presenteras också. 

8.1 Slutsatser/förutsättningar 

Innan man sätter sig ner och börjar implementera en 

komponent för ett existerande system, bör detta gås igenom 

ordentligt. Man bör under genomgången titta på hur ett 

eventuellt grafiskt användargränssnitt används i systemet och 

hur systemet är uppbyggt. Det system, Klipp (se 3.1 Det 

existerande systemet), som använts under arbetet visade sig ha 

en gynnsam uppdelning och när väl utvecklingsmiljö och 

server konfigurerats korrekt flöt arbetet med design och 

implementation av exempelsystemet på relativt smidigt. 

Under examensarbetes senare del har ytterligare ett system 

gåtts igenom för att se om en komponentifiering av detta vore 

möjligt. Detta är inte beskrivet i rapporten tidigare, men det 

kan nämnas att dess uppbyggnad inte var alls lika gynnsam. 

Det förekom mängder av kopplingar mellan systemets 

moduler och användargränssnittet var inte lika väl avskilt från 

den verkliga intelligensen i systemet. På vissa ställen krävdes 

dubblering av kod och en stor mängd kontroller för att 

komponenten skulle kunna användas från ett webbgränssnitt. 

Skulle ett annat medium användas för att öka tillgängligheten 

krävs andra konstruktioner. 

De egenskaper som är speciellt viktiga för att en 

komponentifiering av ett system ska vara enkel att utföra är: 

• En bra struktur med väl avskilda gränser mellan 

underliggande intelligens och användargränssnitt. 

• Bra minneshantering. 

• Korrekt hantering av databaser, om sådana kopplingar 

finns. 

• Väldokumenterad kod. 

• Få och enkla kopplingar mellan delarna i systemet. 

75

76 


Klipp visade sig ha alla dessa egenskaper, medan det andra 

systemet inte helt uppfyllde första och sista punkten. 

8.2 Resultat 

Som säkert framkommit av tidigare delar i rapporten lyckades 

komponentifieringen bra. En komponent utvecklades med ett 

tillhörande webbgränssnitt. Systemet gjordes tillgängligt för 

användning hos Telia AB och reaktionerna från dessa 

användare var positiva. Den version som finns tillgänglig just 

nu är lite längre utvecklad än den som presenteras i rapporten, 

framför allt när det gäller webbgränssnittet. 

Verkligen intressant att notera är att komponenten även 

användes i en systemuppbyggnad som bygger på DCOM. 

Detta visar att om en väl utvecklad och genomtänkt 

komponent skapas, kan denna användas i flera olika 

tillämpningar. Detta är ett av de viktigaste målen med 

komponentifieringar. Kan komponenten användas i flera olika 

tillämpningar ökar tillgängligheten hos det ursprungliga 

systemet markant. 

Om man tittar på de uppsatta målen för examensarbetet (se 

2.2 Målbeskrivning) så har dessa uppnåtts till någonstans 

mellan nivå fyra och fem. Exempelsystemet är implementerat 

och kan tas i bruk, men finns för tillfället bara tillgängligt för 

ansvariga hos Telia AB. Det finns alltså i skarp miljö, men 

används inte annat än för att visa att möjligheten till 

komponentifiering och tillgänglighet via ett webbgränssnitt 

finns. Detta kommer säkert att ändras i framtiden och 

systemet, visserligen antagligen i mer utvecklad version, 

kommer att användas istället för det existerande stationära 

systemet. 

Nedan ges en återkoppling till uppsatta mål (se 2.2 

Målbeskrivning): 

1. Undersökning och utredning av tillgängliga tekniker. 

Genomförd. 

2. Delar av systemet simulerat. Uppnått genom 

prototyputveckling. 

3. Några delar av systemet implementerat som avsett. 

Uppnått.


4. De flesta delarna av systemet fungerar som avsett. 

Uppnått. 

5. Ett demonstrationsexemplar i skarp miljö. Uppnått med 

restriktionen att systemet är tillgängligt endast för vissa 

ansvariga på Telia AB enligt ovan. 

8.3 Erfarenheter 

En mängd erfarenheter har erhållits under examensarbetets 

gång. Framför allt inom Windowsprogrammering och då 

speciellt inom området COM och DCOM. Personligen tycker 

jag att DCOM-delen var intressant. 

Innan arbetet påbörjades hade jag använt Microsoft Visual 

Studio 6.0, men inte alls på samma nivå som nu krävdes. 

Utvecklingsmiljöns interaktion med resten av 

operativsystemet är imponerande, speciellt möjligheten att 

debugga komponenter och DLL-filer. En bra debugger gör 

utvecklingsarbetet mycket lättare och resultaten blir 

följaktligen bättre. 

Även webbutvecklingen har varit intressant och lärorik. Här 

har ASP, XML, XSL, XSLT och IIS varit grunden. Mina 

erfarenheter inom dessa områden har tidigare varit 

begränsade. Under arbetets gång har dock kunnandet inom 

dessa områden ökat. 

Det som gjort arbetet relativt enkelt är, förutom strukturen på 

det ursprungliga systemet, att mängden dokumentation som 

finns att tillgå inom alla dessa områden är stor. Microsoft 

Developer Network (MSDN) har använts flitigt, både via 

Internet och via den varianten som installeras lokalt på 

utvecklingsdatorn. Om inte önskad information funnits där 

har diverser nyhetsgrupper använts, framför allt via Google 

Diskussionsgrupper [27]. 

77

9 Begreppslista 

Begreppslista 

Följande begrepp och förkortningar används i rapporten. 

Dessa är speciellt viktiga för förståelsen av texten. 

ADO/ADODB – ActiveX Data Objects (DataBase) 

Programmeringsmodell från Microsoft som innehåller olika 

typer av gränssnitt för datahantering. Exempel på ett sådant 

gränssnitt är just ADODB. 

COM – Component Object Model 

Microsofts standard för komponenter [6]. Modellen bygger på 

ett s.k. Object Remote Procedure Call (se ORPC) lager genom 

vilket metodanrop kan göras. Viktigaste delen i modellen är 

IDL-filen. 

CSS - Cascading Stylesheets 

En stylesheet-standard som kan användas tillsammans med 

HTML. 

DCOM – Distributed Component Object Model 

En utökning av COM som möjliggör distribuerade 

komponenter. 

DCOMCNFG – DCOM Config 

Ett verktyg, som ingår i Microsoft Windows [13], för att 

konfigurera komponenter (COM/DCOM) när det gäller 

rättigheter att skapa och använda dessa. 

Debug 

Översatt till svenska betyder debug avlusa. Vad man gör är att 

man med hjälp av en s.k. debugger kontrollerar koden genom 

att köra sitt program kodrad för kodrad. Oftast finns en 

debugger tillgänglig i utvecklingsmiljön. 

Debugger 

Verktyget som används för att steg för steg köra sitt program 

och hitta fel. Följer oftast med utvecklingsmiljön. 

DLL – Dynamic Linked Library 

Dessa bibliotek är vanligt förekommande i operativsystem 

som ingår i Microsoft Windows-familjen. Biblioteken är 

kompilerade och länkade enheter som innehåller 

funktionalitet. De kan importeras och användas av andra 

program. Man kan länka in biblioteken statiskt eller 

dynamisk. 

79

80 

Begreppslista 

Dynamisk länkning 

Färdiga programbibliotek länkas inte in i den exekverbara 

enheten. Denna innehåller istället referenser till biblioteken. 

Biblioteken finns alltså inte inuti den exekverbara enheten, 

utan laddas vid behov. 

GUID – Globally Unique Identifier 

Ett identitetsnummer som används för att exempelvis 

identifiera gränssnitt (IID) för olika komponenter. Detta 

nummer genereras genom att väga in diverse faktorer vilket 

medför att två gränssnitt inte kan få samma identitet. 

HTML – Hyper Text Markup Language 

Standard för att presentera webbsidor i en webbläsare. 

Innehåller ett antal s.k. taggar (tags) för att presentera 

informationen som man vill. Det finns flera versioner av 

HTML, standardiserade av W3C [10]. 

IDL – Interface Definition Language 

Det gränssnitt som finns tillgängligt för att kommunicera med 

komponenten specificeras med hjälp av detta språk. 

Definitionen kan ses som ett kontrakt mellan klienten 

(användaren) och serveren (komponenten) och återfinns i en 

s.k. IDL-fil. 

IID – Interface Identifier 

En instans av GUID som används för att identifiera ett 

gränssnitt (interface). 

Interface 

Gränssnitt genom vilket kommunikation mellan exempelvis 

komponenter kan ske. 

JavaRMI – Java Remote Method Invocation 

Javastandard för distribuerade objekt och komponenter. 

JavaScript 

Scriptspråk för att hantera händelser på en webbsida på 

klientsidan. 

Klipp 

Det existerande systemet som används för att exemplifiera 

problemen och lösningar vid komponentifiering (se 3.1, Det 

existerande systemet). 

Kompilator 

Program som används för att översätta den textbaserade 

programkoden till maskinkod. Kompilatorn kontrollerar även

Begreppslista 

syntaxen hos källkoden och ger felmeddelanden om fel skulle 

förekomma i denna. Varje kompilator är konstruerad för att ta 

hand om ett visst programspråk. 

Kompilera 

Översätta den textbaserade källkoden till maskinkod i form av 

s.k. objektfil. Om fel skulle förekomma i källkoden kommer 

inte denna att översättas till maskinkod. 

Länkningsprogram, länkare 

Program för att sätta samman de olika delarna, objektfilerna, 

till ett körbart program. Länkaren producerar en enda enhet, 

en exekverbar fil eller ett bibliotek. 

MFC – Microsoft Foundation Class Library 

Bibliotek som består av klasser, globala funktioner, globala 

variabler och macro. Med dessa kan man utföra diverse 

operationer i Windows, exempelvis rita fönster, effektivt 

hantera strängar m.m. 

Objektfil 

Den fil som kompilatorn producerar. Filen innehåller 

översättningen av källkoden i form av objektkod. 

ODBC – Open DataBase Connectivity 

Programmeringsgränssnitt för att göra det möjligt för 

applikationer att koppla upp sig mot databaser, oavsett format, 

och ställa frågor (queries) till dessa. 

RPC – Remote Procedure Call 

Metodanrop från en process till en annan. Den anropande 

processen verkar som klient, medan den andra verkar som 

server. 

Runtime 

Den tid under vilken exekvering av en komponent eller 

program varar. 

SCM – Service Control Manager 

SCM fungerar som en central träffpunkt för alla 

aktiveringsförfrågningar av komponenter. Varje maskin som 

stöder COM har en egen lokal SCM som skickar vidare 

förfrågningar till SCM på andra maskiner om det är frågan om 

distribuerade komponenter. 

Statisk länkning 

Färdiga moduler, bibliotek, länkas in i programmet vid 

81

82 

Begreppslista 

länkningstillfället. Biblioteket blir då inkapslat i den 

exekverbara enheten. 

Stylesheet 

En fil bestående av en definition på hur informationen i ett 

webbdokument ska presenteras. Man kan styra färger, 

indentering mm. Används ofta tillsammans med XML, då 

koden ska följa XSL-standard. Det finns även en standard 

som heter CSS. 

XML – eXtensible Markup Language 

En standard utvecklad av The World Wide Web Consortium 

(W3C) [10]. XML [11] möjliggör att presentera information 

på ett bestämt sätt genom att man specificerar ett slags träd 

där man bygger upp sina datatyper. Man presenterar sedan 

informationen med hjälp av ett speciellt språk tillsammans 

med ett s.k. stylesheet. 

XSL - eXtensible Stylesheet Language 

En stylesheet-standard som används tillsammans med XML. 

Se även CSS.

10 Referenser 

Referenser 

Följande informationskällor har använts under 

examensarbetet. I de flesta fallen är det materialet hämtat från 

Internet och därför anges ett extra datum i referensen. Detta 

datum anger då referensen fortfarande var tillgänglig. I några 

referenser har viss information utelämnats då denna inte finns 

tillgänglig. 

Referenserna har följande format: 

[nummer] Författare (datum). Titel. Institution. Länk, datum 

senast tillgänglig. 

[1] Microsoft Developer Network Home, MSDN Home. 

http://www.msdn.microsoft.com/, 2001-09-10. 

[2] The Object Management Group, OMG. 

http://www.omg.com/, 2001-09-10. 

[3] P. Emerald Chung, Yennun Huang, Shalini Yajnik m.fl. 

DCOM and CORBA Side by Side, Step By Step, and 

Layer by Layer. Bell Laboratories, Lucent 

Technologies, Murray Hill, New Jersey m.fl. 

http://www.cs.wustl.edu/~schmidt/submit/Paper.html, 

2001-09-10. 

[4] Sun Microsystems. http://www.sun.com/, 2001-09-10. 

[5] Microsoft Visual Studio Home Page. 

http://msdn.microsoft.com/vstudio/, 2001-09-14. 

[6] The Component Object Model. 

http://msdn.microsoft.com/library/default.asp?url=/library/enus/com/com_757w.asp, 

2001-09-27. 

[7] Active Server Pages (General). 

http://msdn.microsoft.com/library/default.asp?url=/nhp/defaul 

t.asp?contentid=28000522, 2001-09-14. 

[8] Microsoft Scripting Technologies. 

http://msdn.microsoft.com/scripting/, 2001-09-14. 

[9] Microsoft Visual SourceSafe Home Page. 

http://msdn.microsoft.com/ssafe/default.asp, 2001-09-14. 

[10] The World Wide Web Consortium (W3C). 

http://www.w3.org/, 2001-09-14. 

83

84 

Referenser 

[11] Extensible Markup Language (XML). 

http://www.w3.org/XML/, 2001-09-14. 

[12] Microsoft Corporate Web Site. 

http://www.microsoft.com/ms.htm, 2001-09-23. 

[13] Windows Family Home Page. 

http://www.microsoft.com/windows/default.asp, 2001-09- 

23. 

[14] Don Box (juni 1999). Essential COM. 

[15] JScript. 

http://msdn.microsoft.com/library/default.asp?url=/library/enus/script56/html/js56jsoriJScript.asp, 

2001-10-08. 

[16] VBScript. 

http://msdn.microsoft.com/library/default.asp?url=/library/enus/script56/html/vtoriVBScript.asp, 

2001-10-08. 

[17] Internet Explorer Home Page. 

http://www.microsoft.com/windows/ie/default.asp, 2001-10- 

08. 

[18] HTML Home Page. http://www.w3.org/MarkUp/, 2001- 

10-08. 

[19] The Extensible Stylesheet Language (XSL). 

http://www.w3.org/Style/XSL/, 2001-10-08. 

[20] Microsoft Visual Studio: Microsoft Visual Studio 

.NET – Next Generation. 

http://msdn.microsoft.com/vstudio/nextgen/default.asp, 2001- 

10-08. 

[21] Windows Web Services (IIS). 

http://microsoft.com/technet/treeview/default.asp?url=/technet 

/prodtechnol/iis/Default.asp, 2001-10-08. 

[22] XML Core. 

http://msdn.microsoft.com/library/default.asp?url=/nhp/Defau 

lt.asp?contentid=28000438, 2001-10-08. 

[23] Doxygen homepage. 

http://www.stack.nl/~dimitri/doxygen/, 2001-11-01. 

[24] Microsoft Office – PowerPoint Home Page. 

http://www.microsoft.com/office/powerpoint/default.htm, 

2001-11-02. 

[25] Dr Richard Grimes (1998). Professional ATL COM 

Programming.

Referenser 

[26] Microsoft Web Application Stress Tool. 

http://webtool.rte.microsoft.com/, 2001-11-13. 

[27] Google Diskussionsgrupper. http://groups.google.com/, 

2002-03-28. 

85

A. COM/DCOM 

Appendix A – COM/DCOM 

Avsnittet innehåller en kort introduktion till COM/DCOM. 

Framför allt handlar det om COM eftersom DCOM endast är 

en utökning med COM som grund. 

Informationen är tagen ur [14] och [25]. 

Det bör påpekas att de komponenter som skapades under 

komponentifieringen av Klipp var enkla på så sätt att 

komponenten existerade s.k. in-process. För mer information 

om detta se A.2, Arkitekturen hos COM/DCOM. 

A.1 Allmänt om COM/DCOM 

COM står för ”Component Object Model” och är alltså en 

modell för hur programkomponenter ska se ut. DCOM står för 

”Distributed Component Object Model”. Framför allt 

utvecklas komponenterna i programspråken C++ och Visual 

Basic, men man kan även använda andra språk som klarar av 

att bygga upp pekarstrukturer och att anropa funktioner med 

hjälp av pekare. Modellen är därför helt plattformsoberoende. 

Klient 

Klient 

Figur 13. Generell bild över COM. Server är själva komponenten. 

Det finns speciellt en viktig del i modellen och det är det 

gränssnitt (interface) som ligger som grund för varje 

komponent. Gränssnittet är det som syns utåt och möjliggör 

användning av den funktionalitet som finns inuti 

komponenten. När det gäller gränssnitt så finns det ett antal 

speciellt viktiga sådana (se A.3, Gränssnittet, och A.3.1, 

Viktiga gränssnitt i COM/DCOM): 

• IUnknown 

Gränssnitt 

Gränssnitt 

Gränssnittspekare 

Gränssnittspekare 

Server Server 

Klass 

Klass 

Metod Metod 1 

1 

Metod Metod 2 

2 

... 

... 

87

88 


• IClassFactory 

• IDispatch 

Nedan, se A.3, Gränssnittet, ges en beskrivning av gränssnitt 

enligt COM/DCOM. 

A.2 Arkitekturen hos COM/DCOM 

Som nämndes ovan skapades komponenter som var s.k. inprocess-komponenter 

under komponentifieringen av Klipp. 

Dessa existerade i form av DLL-servrar, i DLL-filer. Man kan 

även skapa komponenter som fungerar som fristående EXEservrar, 

kallade local eller out-of-process servers. 

Arkitekturen hos dessa två skiljer sig åt genom att in-processservrar 

kan användas direkt utan att något annat än DLL-filen 

för servern finns tillgänglig. Detta ser då ut som i figuren 

ovan (Figur 13). För en out-of-process server ser arkitekturen 

ut enligt figuren nedan (Figur 14). 

Client 

Client 

COM 

COM 

COM 

COM 

Klient Client 

Client 

COM 

COM 

COM 

COM 

Klient Komponent 

Komponent Component 

Component 

run-time run-time run-time run-time run-time run-time run time 

run-time run-time run-time run-time run-time run-time run time 

Security 

Security 

Provider 

Provider 

LPC 

LPC 

DCE DCE RPC 

RPC 

Security 

Security 

Provider 

Provider 

LPC 

LPC 

DCE DCE RPC 

RPC 

Figur 14. COM-arkitekturen för out-of-process server. 

I figuren ovan syns servern i den högra delen och klienten i 

den vänstra. Det som betecknas ”Sequrity Provider” är de 

delar som tar hand om säkerheten för komponenten (se A.5, 

Säkerhet). ”DCE RPC” står för Distributed Computing 

Environment Remote Procedure Call och har hand om 

uppslagningen och anrop av metoderna i komponenten. LPC 

står för Local Procedure Call och har hand om 

kommunikationen mellan processerna. Klienten och servern 

exekverar lokalt på samma dator. 

Ett mål med de olika arkitekturerna är att detta ska vara helt 

transparent för användarna av komponenten. Det skiljer inget 

i hur man skapar instanser av serverobjekten eller hur man 

använder dessa. Vilken modell man använder beror på i 

vilken omgivning komponenten skall användas.


Arkitekturen för DCOM ser ut ungefär som COMs out-ofprocess 

servrar. LPC är utbytt mot en protokollstack och 

mellan klienten och servern sker kommunikationen med hjälp 

av DCOM Network Protocol enligt nedan (Figur 15). 

Client 

COM 

Client 

COM 

COM 

Client 

COM 

COM 

COM 

Klient Client 

COM 

Client 

COM 

COM 

Client 

COM 

COM 

COM 

Klient Komponent 

Komponent Component 

Component 

run-time run-time run-time run-time run time 

run-time run-time run-time run-time run time 

Security 

Security 

Provider 

Provider 

Protocol Protocol Stack 

Stack 

A.3 Gränssnittet 

DCE DCE RPC 

RPC 

Security 

Security 

Provider 

Provider 

DCOM DCOM Network Network Protocol 

Protocol 

Protocol Protocol Stack 

Stack 

DCE DCE RPC 

RPC 

Figur 15. Arkitektur DCOM 

Gränssnittet är det som ligger till grund för hela 

komponenten. Utan gränssnittet skulle en komponent vara 

helt oanvändbar eftersom det är gränssnittet som gör det 

möjligt att utföra metodanrop m.m. in i komponenten. För att 

kunna referera till ett gränssnitt måste ett unikt id för varje 

gränssnitt genereras. Detta id kallas GUID, Globally Unique 

Identifier, och är ett 128-bitars tal. Det är garanterat att vara 

unikt både i tid och i rum. Gränssnittet definieras i en s.k. 

IDL-fil, Interface Definition Language. Denna fil kompileras 

med hjälp av en IDL-kompilator, MIDL.EXE. Under det här 

examensarbetet användes ”Microsoft MIDL Compiler 

Version 5.01.0164” som kommer som en del av Microsoft 

Visual Studio 6.0 [5]. När en IDL-fil kompileras skapas ett 

antal filer enligt nedan (Figur 16). 

89

90 

MinCOM.h 

MinCOM.h 

MinCOM.h 

MinCOM .h 

C/C++ 

C/C++ 

Typdefinitioner 

Typdefinitioner 

MinCOM_P.c 

MinCOM_P.c 

MinCOM_P.c 

MinCOM _P.c 

Marshalerns 

Marshalerns 

definitioner 

definitioner 


MinCOM.IDL 

MinCOM.IDL 

MinCOM.IDL 

MinCOM .IDL 

MIDL.EXE 

MIDL.EXE 

MinCOM_I.h 

MinCOM_I.h 

MinCOM_I.h 

MinCOM _I.h 

GUID 

GUID 

Definitioner 

Definitioner 

DLLDATA.c 

DLLDATA.c 

Marshalerns 

Marshalerns 

serverkod 

serverkod 

Figur 16. Filer som skapas av IDL-kompilatorn 

De filer som behövs för att använda komponenten är 

MinCOM.h, som innehåller ”C/C++ Typdefinitioner”, och 

MinCOM_I.h, som innehåller ”GUID Definitioner”. Dessa 

filer innehåller tillräckligt med information för att skapa 

instanser av komponenten, så länge denna är registrerad och 

tillgänglig i det operativsystem där den ska användas. 

Filerna MinCOM_P.c och DLLDATA.c används vid s.k. 

marshaling (se A.8, Marshaling). 

Under varje gränssnitt finns en eller flera klasser som 

implementerar funktionaliteten som definierats i IDL-filen. 

Dessa klasser behöver inte finnas tillgängliga för användning 

av komponenten. Detta betyder alltså att implementationen av 

komponenten är helt skild från gränssnittet och inte alls synlig 

för den som vill använda komponenten. 

A.3.1 Viktiga gränssnitt i COM/DCOM 

MinCOM.TLB 

MinCOM.TLB 

MinCOM.TLB 

MinCOM .TLB 

Tokenbaserad Tokenbaserad IDL-fil IDL-fil IDL-fil IDL fil 

För För Visual Visual Basic, Basic, Java Java mm. 

mm. 

Det finns ett antal speciellt viktiga gränssnitt i COM/DCOM, 

som nämnts ovan. Nedan beskrivs dessa kort tillsammans med 

en listning av IDL-filen för vart och ett.

IUnknown 


Det här gränssnittet ligger till grund för alla andra gränssnitt. 

Alla gränssnitt som skapas MÅSTE ärva från IUnknown. 

Gränssnittet innehåller de tre viktigaste metoderna för hela 

COM/DCOM: 

• QueryInterface (REFIID riid, void **ppv) 

• AddRef (void) 

• Release (void) 

Se listning nedan (Listning 7). 

QueryInterface 

Metoden används under exekveringen (runtime) för att ta reda 

på typer och metoder i gränssnittet. Den kan jämföras med 

C++ inbyggda operator dynamic_cast, som används för att 

utföra typkonvertering under exekveringen. 

AddRef 

Metoden används för att notifiera objektet, som används för 

att implementera komponenten, att en ny gränssnittspekare 

(interface pointer) har skapats. Under exekveringen av en 

komponent finns det en räknare som indikerar hur många 

gränssnittspekare som skapats. Metoden ökar denna räknare 

med ett. Räknaren ligger till grund för minneshanteringen. Så 

länge räknaren har ett värde större än noll existerar det pekare 

till gränssnittet och komponenten måste finnas i minnet. Så 

fort räknaren antar värdet noll frigörs minnet som 

komponenten använder. 

Release 

Det här är motsatsen till AddRef. Metoden minskar räknaren, 

som håller reda på antalet gränssnittspekare, med ett. Skulle 

räknaren anta värdet noll frigörs det minne som komponenten 

allokerar (se AddRef). 

[ 

] 

local, 

object, 

uuid(00000000-0000-0000-C000-000000000046), 

pointer_default(unique) 

91

92 

interface IUnknown 

{ 

} 


typedef [unique] IUnknown *LPUNKNOWN; 

HRESULT QueryInterface( 

ULONG AddRef(); 

ULONG Release(); 

IClassFactory 

[in] REFIID riid, 

[out, iid_is(riid)] void **ppvObject); 

Listning 7. Gränssnittet IUnknown 

Gränssnittets viktigaste uppgift är att skapa instanser av 

COM/DCOM-objekt. Detta görs med metoderna 

CreateInstance eller RemoteCreateInstance. Metoderna 

LockServer och RemoteLockServer anropas internt av COM 

när s.k. out-of-process activation används (se A.4.1, 

Aktivering (activation) och A.6, Process/trådmodell 

(threading model)). Notera att det här gränssnittet ärver från 

IUnknown (se Listning 8). 

[ 

] 

local, 

object, 

uuid(00000001-0000-0000-C000-000000000046) 

interface IClassFactory : IUnknown 

{ 

typedef [unique] IClassFactory * LPCLASSFACTORY; 

[local] 

HRESULT CreateInstance( 

[in, unique] IUnknown * pUnkOuter, 


[out, iid_is(riid)] void **ppvObject); 

[call_as(CreateInstance)] 

HRESULT RemoteCreateInstance( 

[local] 


[out, iid_is(riid)] IUnknown ** ppvObject);

} 


HRESULT LockServer([in] BOOL fLock); 

[call_as(LockServer)] 

HRESULT __stdcall RemoteLockServer([in] BOOL fLock); 

IDispatch 

Listning 8. Gränssnittet IClassFactory 

IDispatch används för att tillåta att objekt används från 

exempelvis VBScript eller JScript. Gränssnittet måste till för 

att stödja funktionalitet i de interpretativa språken som 

scriptspråken tillhör. 

Metoden GetTypeInfo returnerar en beskrivning av 

gränssnittet och GetTypeInfoCount returnerat 1 om en sådan 

beskrivning finns, annars 0. 

GetIDsOfNames returnerar s.k. DISPIDs, id för metoderna i 

gränssnittet, och Invoke används för att anropa en metod. 

Notera att det här gränssnittet ärver från IUnknown (se 

Listning 9). 

[ 

] 

object, 

uuid(00020400-0000-0000-C000-000000000046) 

interface IDispatch : IUnknown { 

typedef struct tagDISPPARAMS { 

[size_is(cArgs)] VARIANTARG * rgvarg; 

[size_is(cArgs)] DISPID * rgdispidNamedArgs; 

UINT cArgs; 

UINT cNaedArgs; 

} DISPPARAMS; 

HRESULT GetTypeInfoCount([out] UINT * pctinfo); 

HRESULT GetTypeInfo([in] UINT iTInfo, 

HRESULT GetIDsOfNames( 

[in] LCID lcid, 

[out] ITypeInfo ** ppTInfo); 


[in,size_is(cNames)] LPOLESTR * rgszNames, 

[in] UINT cNames, 


[out,size_is(cNames)] DISPID * rgid); 

93

94 

} 


HRESULT Invoke( [in] DISPID id, 

A.4 Klasser/objekt 



[in] WORD wFlags, 

[in, out] DISPPARAMS * pDispParams, 

[out] VARIANT * pVarResult, 

[out] EXCEPINFO * pExcepInfo, 

[out] UINT* puArgErr); 

Listning 9. Gränssnittet IDispatch 

I COM/DCOM måste det finnas ett s.k. klassobjekt (class 

object). För varje klass som ingår i ett gränssnitt finns ett 

klassobjekt som implementerar funktionaliteten hos de olika 

metoderna. Klassobjektet fungerar som en metaklass för en 

given implementation och metoderna som implementeras här 

fungerar som statiska medlemsmetoder i C++. För att komma 

åt funktionaliteten i en komponent går man via detta 

klassobjekt. 

A.4.1 Aktivering (activation) 

Klassobjektet måste aktiveras på något sätt, innan man kan 

använda metoderna. Detta kallas activation och kan göras på 

tre sätt: 

• Klienten ber komponenten att allokera eller binda 

klassobjektet för en given klass. 

• Klienten ber komponenten att skapa en ny instans av en 

klass baserat på klass-id, CLSID. 

• Klienten ber komponenten att väcka ett redan skapat 

objekt baserat på objektets tillstånd. 

Första modellen är nödvändig för att kunna använda 

komponenten, medan de två andra är optimeringar av den 

första. 

Alla tre aktiveringsmodellerna använder SCM, Service 

Control Manager. Modellerna kallas aktiveringsprimitiver, 

activation primitives, och ser ut enligt nedan.


CoGetInstanceFromFile 

CoCreateInstanceEx 

Figur 17. SCM och de tre aktiveringsprimitiverna 

Som syns i figuren ligger CoGetClassObject som grund för de 

andra två, som nämnts ovan. CoGetClassObject ser ut enligt 

nedan: 

HRESULT CoGetClassObject( 

Service Control Manager 

(SCM) 

CoGetClassObject 

[in] REFCLSID rclsid, // vilket klassobjekt? 

[in] DWORD dwClsCtx, // lokalitet? 

[in] COSERVERINFO *pcsi, // värd/säkerhetsinfo 

[in] REFIID refiid, // vilket interface? 

[out, iid_is(riid)]void **ppv); // objektspekare 

Listning 10. Definitionen av CoGetClassObject 

Första argumentet pekar ut vilket klassobjekt som ska 

aktiveras. Det andra argumentet, dwClsCtx, talar om var 

objektet finns, alltså om det är ett inprocess-, out-of-process- 

eller off-host-objekt. Argumentet *pcsi är en pekare till en 

struktur som innehåller information om värden och säkerhet. 

Argumentet gör det möjligt för klienten att bestämma vilken 

maskin som ska aktivera objektet samt konfigurera säkerheten 

för objektet när det gäller att överföra information till och från 

detta (se vidare om säkerhet A.5, Säkerhet). Fjärde 

argumentet är id för klassen som definierar klassobjektet. Det 

sista argumentet är en pekare till objektet som ska aktiveras. 

Objektet kommer att läggas där denna pekare visar och man 

kan sedan med hjälp av denna komma åt metoder och attribut 

hos objektet. 

95

96 

A.5 Säkerhet 


Den första versionen av COM brydde sig inte om något vad 

gäller säkerhet. Detta ändrades dock när Microsoft [12] 

släppte operativsystemet Windows NT 4.0 [13]. Med ökad 

säkerhet kunde man låta vilken maskin som helst på ett 

nätverk använda komponenter på andra maskiner. 

Säkerheten i COM delas upp i tre områden: 

• Autenciering 

• Åtkomstkontroll 

• Hantering av s.k. tokens 

Säkerheten inom COM är ett mycket stort område, vilket gör 

att dessa endast beskrivs kort. Avsnitten är till för att ge en 

liten inblick i begreppen, inte någon ingående kunskap om 

alla olika inställningar eller metoder att sköta om dessa. 

A.5.1 Autenciering 

Autenciering hanterar kontroller av vem som använder 

komponenten. Är användaren den han/hon uppger sig vara? 

Denna kontroll kan ske med hjälp av olika protokoll eller 

paket. Dessa är: 

• RPC_C_AUTHN_NONE – Ingen autenciering 

• RPC_C_AUTHN_DCE_PRIVATE – privat DCEnyckel 

(används ej) 

• RPC_C_AUTHN_DCE_PUBLIC – publik DCE-nyckel 

(används ej) 

• RPC_C_AUTHN_DEC_PUBLIC – Digital Equipment 

(används ej) 

• RPC_C_AUTHN_WINNT – Windows NT LAN 

Manager-autenciering 

• RPC_C_AUTHN_GSS_KERBEROS – Kerberos 

• RPC_C_AUTHN_MQ – Microsoft Message Queue 

• RPC_C_AUTHN_DEFAULT – Standardautenciering 

Som syns i listan ovan finns det ett antal olika paket för 

autenciering. Vilka paket som stöds beror på vilket 

operativsystem som används. I Windows NT 4.0 stöds endast 

RPC_C_AUTHN_WINNT (NTLM) medan i NT 5.0


(Windows 2000) finns stöd för åtminstone NTLM och 

Kerberos. Detta gäller så länge inga 3:e-parts-paket 

installeras. Varje komponent kan konfigureras för att använda 

olika autencieringsnivåer eller paket. DCE RPC och COM 

stöder sex nivåer på autenciering. Dessa varierar från att ingen 

kontroll förekommer till full kryptering av all kommunikation 

mellan komponent och användare, enligt nedan. 

• (RCP_C_AUTHN_LEVEL_DEFAULT) 

• RPC_C_AUTHN_LEVEL_NONE 

• RPC_C_AUTHN_LEVEL_CONNECT 

• RPC_C_AUTHN_LEVEL_CALL 

• RPC_C_AUTHN_LEVEL_PKT 

• RPC_C_AUTHN_LEVEL_PKT_INTEGRITY 

• RPC_C_AUTHN_LEVEL_PKT_PRIVACY 

Nivåerna är ordnade från låg till hög nivå, där en högre nivå 

innebär att alla nivåer lägre antas fungera korrekt. 

RPC_C_AUTHN_LEVEL_NONE innebär att ingen kontroll 

görs, RPC_C_AUTHN_LEVEL_CONNECT innebär att 

kontroll görs vid första metodanropet. 

A.5.2 Åtkomstkontroll 

Åtkomstkontrollen är uppdelad i två delar, rättigheter i 

samband med start av serverprocess samt åtkomsträttigheter. 

Den första kontrollen används för att se vem som har 

rättigheter att starta en serverprocess när anrop görs till SCM 

(se A.4.1, Aktivering (activation)). Åtkomsträttigheter innebär 

kontroll av vilka som har rättigheter att använda objekt i 

serverprocessen när en sådan startats. Båda typerna kan ställas 

in med hjälp av verktyget DCOMCNFG.EXE, medan det bara 

är åtkomsträttigheterna som kan ställas in vid runtime. Den 

senare kontrollen görs gentemot värden som ligger sparade i 

Windowsregistret. 

A.5.3 Hantering av tokens 

I Windows NT har alla processer en s.k. ”access token”, som 

innehåller säkerhetsattributen för processen. Denna token 

skapas när en process initieras och innehåller bland annat 

information om användare, användarens s.k. ”NT security 

97

98 


identifier (SID)”, listan med grupper användaren tillhör etc. 

Med hjälp av dessa tokens håller COM reda på vem eller vilka 

som har rättigheter att utföra operationer med komponenterna, 

processerna och objekten som ingår i modellen. 

A.6 Process/trådmodell (threading model) 

Att välja process- eller trådmodell, engelskans threading 

model, för en komponent är inte alltid lätt. Innan man 

bestämmer detta måste man ta ett beslut om komponenten ska 

vara DLL-server eller en EXE-server, vilket är nära besläktat 

med in-process- eller out-of-process-komponenter enligt ovan 

(se A.2, Arkitekturen hos COM/DCOM, och A.4.1, 

Aktivering (activation)). Det finns fyra olika modeller att 

välja mellan när det gäller threading models: 

• Single 

• Apartment 

• Free 

• Both 

Dessa skiljer sig åt när det gäller prestanda och trådsäkerhet. 

Modellerna beskrivs kort nedan. 

Vilken modell man väljer beror helt och hållet på var och hur 

komponenterna ska användas. Olika modeller är bra i olika 

tillämpningar. 

A.6.1 Single-threading 

Som namnet antyder är det en enda huvudtråd som är 

inblandad i hanteringen av objekt av den här typen. Alla anrop 

till objekten är serialiserade genom en enda tråd, vilket gör att 

de behandlas i den följd de kommer in. Modellen 

rekommenderas inte när det gäller komponenter som ska 

användas från exempelvis ASP-script via ett webbgränssnitt, 

eftersom single-threaded-komponenter inte kan hantera 

många klienter samtidigt. Resultatet av detta kan vara s.k. 

dead-lock, klienttrådarna väntar på varandra i all oändlighet, 

en låsning.

A.6.2 Apartment-threading 


Den här modellen används som standardmodell om man 

väljer att göra en EXE-server med hjälp av ATL COM 

AppWizard i Visual C++. Alla objekten på servern skapas 

inom en s.k. STA, Single Threaded Apartment. Denna 

egenskap åskådliggörs enklast med hjälp av en figur (Figur 

18). 

Klient 

Klient 

Klient 

Klient 

Klient 

Server 

STA 

Objekt 

Objekt 

Objekt 

Objekt 

Objekt 

Figur 18. Apartment-threading model i EXE-server 

Här ser vi fem klienter som har skapat varsitt objekt på 

servern. Dessa objekt existerar i en och samma STA. Anropen 

är även här serialiserade och behandlas alltså i den ordning de 

inkommer till servern. Detta kan resultera i att klienttrådar 

låser. Sådana här objekt kan användas från ASP-script om 

instanserna existerar under det att webbsidan genereras, alltså 

inte för objekt som existerar under en hel webbsession. 

Om servern är av DLL-typ kommer en STA skapas för varje 

instans av objekten och problemet med serialiserade 

metodanrop försvinner, vilket gör att man slipper låsta 

klienttrådar. Figuren nedan (Figur 19) åskådliggör utseendet 

på modellen. 

99

100 

Klient 

Klient 

Klient 

Klient 

Klient 

A.6.3 Free-threading 


Server 

STA 

Objekt 

STA 

Objekt 

STA 

Objekt 

STA 

Objekt 

STA 

Objekt 

Figur 19. Apartment-threading model i DLL-server 

En server med en free-threading modell ser ut ungefär som 

apartment-threaded server, men objekten exekverar i en s.k. 

MTA, Multi Threaded Apartment. Figuren nedan (Figur 20) 

åskådliggör modellen.

Klient 

Klient 

Klient 

Klient 

Klient 


Figur 20. Free-threading model 

Här syns att alla objekt exekverar helt skilda från varandra 

och att inga metodanrop från en klient låser andra klienter. 

Varje metodanrop från en klient till ett objekt skapar en RPCtråd. 

Man kan tycka att den här modellen är den man bör 

använda, men det rekommenderas att man inte använder den i 

komponenter som ska användas från ASP-script i Microsoft 

IIS [21]. 

A.6.4 Both-threading 

RPC 

trådar 

Server 

MTA 

Objekt 

Objekt 

Objekt 

Objekt 

Objekt 

Modellen innehåller både en MTA och en STA. Det krävs 

alltså att man implementerar hantering av båda fallen. Detta 

kan vara tidsödande eftersom man oftast inte behöver stöd för 

båda modellerna i sina komponenter. 

A.7 Arbetsfördelningsmodeller för DCOM 

DCOM innebär att man distribuerar sina komponenter till 

olika maskiner. Man kan utnyttja det här till att lägga likadana 

101

102 


komponenter på många maskiner och sedan fördela arbetet 

mellan dessa komponenter enligt olika modeller. Fördelen 

med att fördela arbetet är att man avlastar enskilda maskiner 

vid tungt arbete. 

Det finns två huvudmodeller för detta: 

• Statisk fördelning 

• Dynamisk fördelning 

Modellerna beskrivs nedan (se A.7.1, Statisk fördelning 

(Static Load Balancing), och A.7.2, Dynamisk fördelning 

(Dynamic Load Balancing)). 

A.7.1 Statisk fördelning (Static Load Balancing) 

Som namnet antyder bestäms vilket arbete som ska utföras på 

vilka maskiner genom en statisk tilldelning. Man kan 

exempelvis dela in klienterna i grupper där varje grupp 

använder komponenten på en egen maskin. Detta kan ge en 

sned arbetsfördelning om många klienter ur en och samma 

grupp skulle behöva komponenten samtidigt. 

Det som talar för statisk arbetsfördelning är att 

konfigureringen är enkel. Från och med Windows 2000 kan 

man centralisera detta, medan man i Windows NT 4.0 kan 

använda sig av exempelvis en databas eller en fil som ligger 

på något för klienterna känt ställe. 

Man kan även sköta fördelningen med en s.k. Referral 

Component, som beroende på klientens identitet kan välja 

server. Det som gör en sådan komponent effektiv är att den 

kan skapa en direktkoppling till servern och returnera den till 

klienten. Referral Component är sedan helt frikopplad från 

resten av kommunikationen mellan klient och server. 

Modellen fungerar bra när man kan förutse belastningen på 

komponenterna. 

A.7.2 Dynamisk fördelning (Dynamic Load Balancing) 

Den här modellen väljer dynamiskt vilken server en klient ska 

koppla upp sig mot. Vilken server som aktiveras bestäms av 

en Referral Component. Man kan exempelvis välja den server 

med den, för tillfället, lägsta belastningen (se Figur 21). Vilka 

kriterier man använder vid val av server är upp till den som 

implementerar systemet. Med den här modellen blir systemet

Klient 


flexibelt och om en server skulle krascha skulle inte det 

märkas på samma sätt som vid statisk arbetsfördelning. 

1. Klienten vill ha en koppling 

A.8 Marshaling 

3. Kopplingen returneras till klienten 

2. Referral Component kontaktar 

”bästa” distribuerade komponent 

Referral Component 

Figur 21. Användning av “Referral Component” 

Komponent 

Komponent 

Komponent 

Komponent 

Komponent 

Komponent 

Marshaling är den procedur som har hand om packning och 

sändning av det data som ska skickas mellan komponenterna 

och klienterna. Eftersom marshaling är ett invecklat område 

kommer det inte att beskrivas i detalj. Man behöver oftast inte 

bry sig om detta eftersom marshaling ingår i COM/DCOMarkitekturen. 

På mottagarsidan, detta kan vara både server och klient 

eftersom klienten skickar metodanrop till servern med eller 

utan parametrar, kommer marshalern att ta emot data och 

packa upp det. Proceduren kallas unmarshaling och är 

omvänd marshaling-procedur. 

För en mer ingående beskrivning av marshaling, läs [14] och 

[25]. 

103

104 

A.8.1 VARIANT 


Egenskaperna för marshaling gör att inte alla typer av data 

kan skickas genom gränssnittet. Proceduren sköts av en s.k. 

marshaler och denna måste veta storlek och struktur på den 

data som ska packas och skickas. En marshaler klarar av att 

hantera datatyper som ryms i strukturen VARIANT. 

Utseendet på strukturen ser ut enligt nedan: 

typedef struct tagVARIANT { 

VARTYPE vt; 

unsigned short wReserved1; 



union { 

Byte bVal; // VT_UI1. 

Short iVal; // VT_I2. 

long lVal; // VT_I4. 

float fltVal; // VT_R4. 

double dblVal; // VT_R8. 

VARIANT_BOOL boolVal; // VT_BOOL. 

SCODE scode; // VT_ERROR. 

CY cyVal; // VT_CY. 

DATE date; // VT_DATE. 

BSTR bstrVal; // VT_BSTR. 

DECIMAL FAR* pdecVal; // VT_BYREF|VT_DECIMAL. 

IUnknown FAR* punkVal; // VT_UNKNOWN. 

IDispatch FAR* pdispVal; // VT_DISPATCH. 

SAFEARRAY FAR* parray; // VT_ARRAY|*. 

Byte FAR* pbVal; // VT_BYREF|VT_UI1. 

short FAR* piVal; // VT_BYREF|VT_I2. 

long FAR* plVal; // VT_BYREF|VT_I4. 

float FAR* pfltVal; // VT_BYREF|VT_R4. 

double FAR* pdblVal; // VT_BYREF|VT_R8. 

VARIANT_BOOL FAR* pboolVal; // VT_BYREF|VT_BOOL. 

SCODE FAR* pscode; // VT_BYREF|VT_ERROR. 

CY FAR* pcyVal; // VT_BYREF|VT_CY. 

DATE FAR* pdate; // VT_BYREF|VT_DATE. 

BSTR FAR* pbstrVal; // VT_BYREF|VT_BSTR. 

IUnknown FAR* FAR* ppunkVal; // VT_BYREF|VT_UNKNOWN. 

IDispatch FAR* FAR* ppdispVal; // VT_BYREF|VT_DISPATCH.

}; 

}; 


SAFEARRAY FAR* FAR* pparray; // VT_ARRAY|*. 

VARIANT FAR* pvarVal; // VT_BYREF|VT_VARIANT. 

void FAR* byref; // Generic ByRef. 

char cVal; // VT_I1. 

unsigned short uiVal; // VT_UI2. 

unsigned long ulVal; // VT_UI4. 

int intVal; // VT_INT. 

unsigned int uintVal; // VT_UINT. 

char FAR * pcVal; // VT_BYREF|VT_I1. 

unsigned short FAR * puiVal; // VT_BYREF|VT_UI2. 

unsigned long FAR * pulVal; // VT_BYREF|VT_UI4. 

int FAR * pintVal; // VT_BYREF|VT_INT. 

unsigned int FAR * puintVal; // VT_BYREF|VT_UINT. 

Listning 11. Strukturen på VARIANT 

Överst i strukturen ovan (Listning 11) finns ett fält, VARTYPE 

vt, som identifierar vilken typ som kapslas in. Värdet på 

VARTYPE vt är kombinationer av konstanter enligt 

kommentarsdelarna i unionen i strukturen. Eftersom 

VARIANT är en väldefinierad struktur vet marshalern hur 

den ska behandla sådana utan att behöva bry sig om vad som 

egentligen gömmer sig inne i VARIANT. Variabeltyperna 

som stöds är de som finns i unionen. Här syns exempelvis 

IUnknown och IDispatch. Eftersom alla gränssnitt i COM 

ärver från något av dessa två kan pekare till olika gränssnitt 

skickas genom gränssnittet. Detta är kraftfullt och har 

utnyttjats i exempelsystemet som implementerats under 

examensjobbet. 

För en mer ingående beskrivning av strukturen VARIANT läs 

exempelvis [1]. 

105

Appendix B – Microsoft IIS och DCOMCNFG 

B. Microsoft IIS och DCOMCNFG 

Innan prototyputvecklingen kunde påbörjas uppkom stora 

problem med att få användningen av komponenter från ASPsidor 

att fungera. Därför har detta appendix kommit till, för att 

underlätta installationen av Microsoft IIS och inställningarna i 

DCOMCNFG. 

B.1 Microsoft IIS 

Med installationen av Microsoft IIS kommer två stycken 

användare, IUSR_DATORNAMN och IWAM_DATORNAMN. 

Som framgår av namnen beror dessa av namnet på datorn, på 

vilken IIS installeras. 

IUSR_DATORNAMN är en användare för anonym access av 

resurser inom IIS. Användaren ingår i gruppen Gäster eller 

Guests om engelsk version av IIS/Windows används. Inga 

inställningar behöver ändras på detta användarkonto. Ändra 

INTE lösenordet för användaren. 

IWAM_DATORNAMN (WAM står för Web Application 

Management) är en användare för IIS om nya processer ska 

aktiveras från ett webbscript eller liknande. Även detta konto 

ingår i gruppen Gäster eller Guests. Samma sak gäller för 

detta konto, som för IUSR-kontot beskrivet ovan, d.v.s. att 

inga inställningar behöver ändras. 

Man kan med dessa två konton begränsa åtkomsten av 

webbsidor på sin server, men detta bör man istället begränsa 

genom att konfigurera IIS på annat sätt. 

IIS konfigureras via en applikation, Internet Information 

Services, som återfinns på kontrollpanelen (Control Panel). 

Från denna kan man skapa nya s.k. virtuella bibliotek, som 

fungerar som mappningar till de verkliga biblioteken på 

servern. Roten för webbservern ligger oftast på 

”C:\Inetpub\wwwroot”. Om man går in i denna katalog via en 

webbläsare inloggad som administrator kan man konfigurera 

webbservern via ett webbgränssnitt. Som standard fungerar 

detta endast från den dator som IIS är installerad på. Detta kan 

107

108 


dock ställas om för att göra det möjligt att konfigurera sin 

webbserver från en annan dator. 

Om man skapar ett virtuellt bibliotek på sin server behöver 

inga inställningar ändras för att få script och 

komponentanvändning via script att fungera. 

B.2 DCOMFNG 

Detta verktyg används för att konfigurera hur COM och 

DCOM ska användas. Oftast behöver inga inställningar 

ändras, men man bör kontrollera exekveringsrättigheterna 

under säkerhetsinställningar. Dessa ska vara inställda så att 

både IUSR_DATORNAMN och IWAM_DATORNAMN har 

rättigheter att exekvera komponenter på servern. Det var 

framför allt detta som skapade problem och förvirring under 

inledningen av prototyputvecklingen. För att undvika problem 

med detta i framtiden återfinns tre figurer nedan (Figur 1, 

Figur 1 och Figur 1), som visar hur det ska se ut under två av 

inställningsflikarna. Observera att dessa är från en engelsk 

version av IIS/Windows.


Figur 22. Inställningar i DCOMCNFG, flik 2. 

109

110 


Figur 23. DCOMCNFG. Klicka på “Edit Defaults”. 

Figur 24. Exekveringsrättigheterna för COM/DCOM. 

Att konfigurera IIS och COM/DCOM är inte helt trivialt. För 

IIS finns ett stort antal inställningar att göra. Dessa är inte helt


självklara och dokumentationen är ganska knapphändig. Man 

bör vara mycket försiktig med detta eftersom det inte finns 

någon möjlighet att återställa till standardinställningar utan att 

installera om hela IIS. 

111

Ökad tillgänglighet av existerande programvara genom ...

Create successful ePaper yourself

Delete template?

Save as template?